Come Metto in Sicurezza WordPress da Attacchi Brute Force: La Mia Procedura

Se gestisci siti WordPress da qualche anno come faccio io, sai benissimo che gli attacchi brute force su wp-login.php sono all’ordine del giorno. Non è questione di “se” verrai attaccato, ma di “quando”. Ogni singolo sito WordPress esposto su Internet riceve tentativi di accesso non autorizzati, spesso da botnet distribuite su centinaia di indirizzi IP diversi. Ho visto server con carichi CPU al 100% semplicemente perché migliaia di richieste POST venivano inviate contemporaneamente alla pagina di login. Il risultato? Siti lentissimi, utenti che non riescono ad accedere e, nel caso peggiore, account amministratore compromessi con conseguenze devastanti: defacement, malware iniettato, dati rubati e reputazione distrutta. Dopo anni di esperienza nella gestione di server e siti WordPress, ho sviluppato una procedura completa e stratificata che applico sistematicamente a ogni installazione che gestisco. In questo articolo ti condivido ogni singolo passaggio.

La mia filosofia di sicurezza si basa su un principio fondamentale: la difesa in profondità. Non mi affido mai a un singolo meccanismo di protezione, ma creo più livelli di sicurezza sovrapposti, in modo che se uno fallisce, gli altri continuino a proteggere il sito. Questo approccio richiede un po’ più di lavoro iniziale, ma ti garantisco che nel lungo periodo ripaga enormemente. Ho messo in sicurezza oltre duecento installazioni WordPress nel corso degli anni, e questa procedura ha ridotto gli incidenti di sicurezza praticamente a zero. Ogni passaggio che troverai qui è stato testato in produzione, affinato dopo aver analizzato migliaia di tentativi di attacco reali e ottimizzato per trovare il giusto equilibrio tra sicurezza e usabilità. Non si tratta di teorie accademiche, ma di soluzioni concrete che puoi implementare subito sul tuo sito, anche se non sei un esperto di cybersecurity. Partiamo dall’inizio: come riconoscere che sei sotto attacco.

1. Identificare gli Attacchi Brute Force nei Log del Server

Il primo passo della mia procedura è sempre quello di analizzare i log del server per capire l’entità del problema. Troppi amministratori non guardano mai i log e si accorgono degli attacchi solo quando il sito diventa irraggiungibile. Io dedico regolarmente tempo alla lettura dei log perché contengono informazioni preziosissime su cosa sta succedendo sul server. Ecco come procedo per identificare i tentativi di brute force in corso.

1. Accedi al server via SSH e naviga nella directory dei log di Apache o Nginx. Su server con Plesk, i log si trovano tipicamente in /var/www/vhosts/tuodominio.it/logs/. Su cPanel, cerca in /home/utente/access-logs/ oppure /var/log/apache2/ per configurazioni standard.
2. Cerca le richieste POST a wp-login.php con questo comando: grep “POST /wp-login.php” access_log | tail -100. Se vedi decine o centinaia di richieste dallo stesso IP o da IP diversi in pochi minuti, sei sotto attacco brute force attivo.
3. Conta le richieste per IP per identificare gli attaccanti principali: grep “POST /wp-login.php” access_log | awk ‘{print $1}’ | sort | uniq -c | sort -rn | head -20. Questo comando ti mostra i 20 IP che hanno fatto più tentativi di login, ordinati per numero di richieste.
4. Verifica anche xmlrpc.php, che è un altro vettore di attacco molto comune: grep “POST /xmlrpc.php” access_log | wc -l. Se il numero è alto, hai un problema anche su quel fronte, che affronteremo più avanti nella guida.
5. Controlla il log degli errori con tail -500 error_log | grep -i “authentication” per trovare eventuali errori di autenticazione fallita che confermano i tentativi di brute force.
6. Monitora in tempo reale con tail -f access_log | grep “wp-login” per osservare gli attacchi mentre accadono. Questo è particolarmente utile quando stai per implementare le contromisure e vuoi verificare che funzionino immediatamente.

Un segnale chiaro di attacco brute force è vedere centinaia di richieste POST a wp-login.php con codice di risposta 200 (la pagina viene caricata correttamente ogni volta) seguite da un redirect 302 solo in rari casi (che indicherebbe un login riuscito). Se noti un 302 tra tanti 200, significa che l’attaccante potrebbe aver indovinato le credenziali. In quel caso, cambia immediatamente tutte le password e verifica l’integrità del sito.

2. Limitare i Tentativi di Login con Plugin Dedicati

Il primo livello di protezione che installo sempre è un plugin che limita il numero di tentativi di login consentiti da un singolo indirizzo IP. È la contromisura più semplice e immediata, e richiede letteralmente due minuti per essere configurata. Questo blocca la maggior parte degli attacchi brute force automatizzati, perché i bot tipicamente provano centinaia di combinazioni utente/password in rapida successione.

1. Installa il plugin “Limit Login Attempts Reloaded” dalla dashboard WordPress: vai su Plugin → Aggiungi Nuovo → cerca “Limit Login Attempts Reloaded” → Installa e Attiva. Questo plugin è gratuito, leggero, ben mantenuto e utilizzato da oltre due milioni di siti WordPress. Io lo preferisco ad alternative più pesanti come Wordfence per questo specifico scopo perché ha un impatto minimo sulle performance.
2. Configura i parametri di blocco accedendo a Impostazioni → Limit Login Attempts. Io utilizzo questi valori: 4 tentativi consentiti, blocco per 20 minuti dopo il superamento dei tentativi, 4 blocchi prima di un blocco esteso di 24 ore. Questi valori sono il risultato di anni di esperienza e bilanciano bene la sicurezza con la possibilità che un utente legittimo sbagli la password qualche volta.
3. Abilita le notifiche email per essere avvisato quando un IP viene bloccato. Imposta la notifica dopo il secondo blocco per evitare di essere sommerso di email durante un attacco massiccio, ma comunque restare informato sui tentativi più persistenti.
4. Aggiungi alla whitelist il tuo IP (o il range di IP del tuo ufficio) per evitare di bloccarti fuori accidentalmente durante le sessioni di lavoro. Vai nella sezione “Whitelist” del plugin e inserisci il tuo indirizzo IP statico.
5. Verifica i log del plugin regolarmente dalla dashboard. Il plugin mostra statistiche dettagliate sui tentativi di login falliti, inclusi gli username provati e gli IP di origine. Queste informazioni sono utilissime per capire il pattern degli attacchi.

Una nota importante: se il tuo sito è dietro un reverse proxy o un CDN come Cloudflare, assicurati che il plugin sia configurato per leggere l’IP reale del visitatore dall’header corretto (tipicamente X-Forwarded-For o CF-Connecting-IP). Altrimenti vedrai tutti i tentativi provenire dallo stesso IP del proxy e il plugin diventerà inefficace, oppure peggio, bloccherà tutti i visitatori perché vedrebbe lo stesso indirizzo IP per chiunque si colleghi al sito.

3. Rinominare wp-login.php e Proteggere con .htaccess

Uno dei metodi più efficaci nella mia procedura è rendere invisibile la pagina di login. Se i bot non trovano wp-login.php, semplicemente non possono attaccarlo. Questo non è “sicurezza tramite oscuramento” come unica misura, ma come livello aggiuntivo è estremamente efficace. Abbinato alle altre protezioni, riduce drasticamente il volume di attacchi che il server deve gestire, con benefici anche sulle performance.

1. Installa il plugin “WPS Hide Login”, che è leggero, gratuito e utilizzato da oltre un milione di siti. Dopo l’attivazione, vai su Impostazioni → WPS Hide Login e cambia l’URL di login da /wp-login.php a qualcosa di personalizzato, ad esempio /accesso-riservato o /mio-login-2024. Evita URL troppo ovvi come /login o /admin. Annota il nuovo URL e comunicalo a tutti gli utenti del sito.
2. Configura la pagina di redirect: quando qualcuno prova ad accedere a /wp-login.php, il plugin può mostrare un errore 404 o reindirizzare a una pagina specifica. Io imposto sempre il redirect a una pagina 404 per non dare indicazioni all’attaccante sul fatto che il sito sia WordPress.
3. Aggiungi protezione .htaccess aggiuntiva alla directory wp-admin. Apri il file .htaccess nella root del sito e aggiungi questa regola per bloccare l’accesso diretto a wp-login.php anche bypassando il plugin:

Ecco il codice .htaccess che utilizzo per proteggere la pagina di login con autenticazione HTTP aggiuntiva:

# Protezione wp-login.php con password HTTP
<Files wp-login.php>
AuthType Basic
AuthName "Area Riservata"
AuthUserFile /home/tuoutente/.htpasswd
Require valid-user
</Files>

Per creare il file .htpasswd, esegui da terminale: htpasswd -c /home/tuoutente/.htpasswd nomeutente e inserisci la password quando richiesto. Il percorso del file .htpasswd deve essere fuori dalla document root del sito web, in modo che non sia accessibile via browser. Questo aggiunge un secondo livello di autenticazione: prima l’utente deve superare l’autenticazione HTTP, poi quella di WordPress.

Un altro blocco .htaccess molto utile è limitare l’accesso al pannello di amministrazione solo a determinati indirizzi IP:

# Limita accesso wp-admin per IP
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-admin [NC]
RewriteCond %{REMOTE_ADDR} !^123.456.789.0$
RewriteCond %{REMOTE_ADDR} !^111.222.333.444$
RewriteRule ^(.*)$ - [F,L]
</IfModule>

Sostituisci gli indirizzi IP con quelli da cui accedi normalmente. Se lavori da IP dinamico, questa soluzione è meno pratica, ma resta utilissima per siti gestiti sempre dallo stesso ufficio con IP statico.

4. Implementare l’Autenticazione a Due Fattori (2FA)

L’autenticazione a due fattori è forse la singola misura più importante che puoi implementare. Anche se un attaccante dovesse indovinare username e password (cosa improbabile con le altre protezioni attive, ma non impossibile), senza il secondo fattore non potrà comunque accedere. Personalmente considero il 2FA obbligatorio per qualsiasi account con privilegi di amministratore. Ecco la procedura che seguo per implementarlo su ogni sito che gestisco.

1. Installa il plugin “WP 2FA – Two-factor Authentication” dalla directory ufficiale di WordPress. Questo plugin è sviluppato da WP White Security, un team specializzato in sicurezza WordPress, ed è la soluzione che preferisco perché offre un ottimo equilibrio tra funzionalità e semplicità d’uso. La versione gratuita è più che sufficiente per la maggior parte dei siti.
2. Attiva il 2FA per tutti gli amministratori: durante il wizard di configurazione iniziale, seleziona “Tutti gli amministratori” come gruppo obbligatorio. Puoi anche estendere il requisito agli editor e agli autori per una protezione più completa, soprattutto su siti multi-autore.
3. Scegli il metodo TOTP (Time-based One-Time Password) come metodo primario. Funziona con app gratuite come Google Authenticator, Authy o Microsoft Authenticator. Io preferisco Authy perché permette il backup cloud dei codici, quindi se perdi il telefono non resti tagliato fuori da tutti i tuoi siti.
4. Configura un metodo di backup: abilita i codici di backup monouso che l’utente può stampare e conservare in un luogo sicuro. Ogni utente riceve tipicamente 10 codici di backup, ognuno utilizzabile una sola volta. Questo è fondamentale per evitare lockout nel caso in cui il telefono con l’app di autenticazione non sia disponibile.
5. Imposta un periodo di grazia ragionevole: se rendi il 2FA obbligatorio, concedi agli utenti 3-5 giorni per configurarlo prima di forzare il blocco dell’accesso. Questo evita problemi con utenti meno tecnici che hanno bisogno di tempo per installare l’app sul telefono e capire il funzionamento del sistema.
6. Testa il funzionamento su un account di prova prima di forzarlo su tutti gli utenti. Verifica che il login funzioni correttamente con il codice TOTP, che i codici di backup funzionino e che il processo di recupero sia chiaro e documentato per tutti gli utenti del sito.

Un’alternativa valida come plugin 2FA è miniOrange Google Authenticator, che offre funzionalità simili con un’interfaccia leggermente diversa. Se gestisci molti siti, valuta anche soluzioni a livello server come moduli PAM per SSH con Google Authenticator, così proteggi sia l’accesso WordPress che quello al server stesso con un approccio unificato alla sicurezza.

5. Disabilitare XML-RPC e Proteggere Endpoint Vulnerabili

Il file xmlrpc.php è uno dei vettori di attacco più sfruttati dopo wp-login.php. Originariamente progettato per consentire la pubblicazione remota di articoli e la comunicazione tra siti WordPress (pingback e trackback), oggi è utilizzato principalmente dagli attaccanti per effettuare brute force amplificati. Attraverso il metodo system.multicall, un singolo request HTTP può testare centinaia di combinazioni di credenziali simultaneamente, rendendo gli attacchi molto più efficienti e difficili da rilevare. Nella maggior parte dei siti che gestisco, XML-RPC non serve e può essere disabilitato completamente senza alcuna conseguenza negativa.

1. Verifica se XML-RPC è necessario: controlla se utilizzi l’app mobile di WordPress, Jetpack o servizi che richiedono XML-RPC. Se non usi nessuno di questi, puoi disabilitarlo senza problemi. L’API REST di WordPress, introdotta dalla versione 4.7, ha sostituito la maggior parte delle funzionalità di XML-RPC in modo più sicuro e moderno.
2. Disabilita XML-RPC via .htaccess aggiungendo questo blocco al file nella root del sito:

# Blocca completamente xmlrpc.php
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

3. In alternativa, usa il plugin “Disable XML-RPC” se preferisci una soluzione gestibile dalla dashboard. Il plugin aggiunge semplicemente un filtro WordPress che disabilita tutte le funzionalità XML-RPC. È la soluzione meno invasiva e più facilmente reversibile.
4. Proteggi anche wp-cron.php da accessi esterni eccessivi. Sebbene non sia un vettore di brute force, un accesso massivo a wp-cron.php può sovraccaricare il server. Disabilita il cron interno di WordPress aggiungendo in wp-config.php: define(‘DISABLE_WP_CRON’, true); e configura un cron di sistema: */15 * * * * wget -q -O – https://tuodominio.it/wp-cron.php?doing_wp_cron > /dev/null 2>&1
5. Blocca l’enumerazione degli utenti aggiungendo in .htaccess:

# Blocca enumerazione utenti via REST API e parametro author
RewriteCond %{QUERY_STRING} ^author=([0-9]+) [NC]
RewriteRule .* - [F,L]

# Blocca accesso diretto alla REST API users endpoint per utenti non autenticati
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users [NC]
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in
RewriteRule .* - [F,L]
</IfModule>

L’enumerazione degli utenti è spesso il primo passo di un attacco brute force: l’attaccante cerca di scoprire gli username validi visitando /?author=1, /?author=2 e così via, oppure interrogando l’API REST. Bloccando questo vettore, costringi l’attaccante a indovinare sia l’username che la password, rendendo l’attacco esponenzialmente più difficile.

6. Configurare Cloudflare e Regole Firewall Avanzate

L’ultimo livello della mia strategia di difesa è Cloudflare, che agisce come primo bastione filtrando il traffico malevolo prima ancora che raggiunga il server. Anche il piano gratuito di Cloudflare offre funzionalità di sicurezza potentissime che, configurate correttamente, bloccano la stragrande maggioranza degli attacchi brute force a livello di rete, senza consumare risorse del tuo server. Questo è particolarmente importante su hosting condivisi dove le risorse sono limitate e un attacco brute force sostenuto può far sospendere il tuo account dall’hosting provider.

1. Attiva la modalità “Under Attack” temporaneamente se sei sotto un attacco massiccio in corso. Questa modalità presenta un challenge JavaScript a tutti i visitatori prima di farli passare, bloccando efficacemente i bot automatizzati. Non lasciarla attiva permanentemente perché rallenta l’accesso per i visitatori legittimi con un’attesa di circa 5 secondi.
2. Crea una regola WAF personalizzata per proteggere wp-login.php. Nella dashboard Cloudflare vai su Security → WAF → Custom Rules e crea una regola con queste condizioni: URI Path contains “/wp-login.php” AND IP Source Address is not in {il tuo IP} → Action: Managed Challenge. Questo presenta un captcha a chiunque non sia tu prima di accedere alla pagina di login.
3. Crea una regola per bloccare xmlrpc.php: URI Path contains “/xmlrpc.php” → Action: Block. Questo blocca tutte le richieste a XML-RPC a livello di Cloudflare, senza nemmeno raggiungere il tuo server.
4. Configura il Rate Limiting: crea una regola che limita le richieste alla pagina di login. Imposta un limite di 5 richieste per minuto per IP verso URL che contengono “wp-login”. Quando il limite viene superato, Cloudflare blocca l’IP per un periodo configurabile. Questa funzionalità è disponibile anche nel piano gratuito con alcune limitazioni.
5. Abilita il Bot Fight Mode nelle impostazioni di sicurezza. Questa funzione utilizza l’intelligenza di rete di Cloudflare per identificare e bloccare automaticamente il traffico proveniente da bot conosciuti come malevoli, compresi quelli usati per attacchi brute force su larga scala.
6. Configura le IP Access Rules per bloccare permanentemente interi range di IP che attaccano ripetutamente. Vai su Security → WAF → Tools e aggiungi blocchi per range di IP notoriamente malevoli. Puoi bloccare per singolo IP, per range CIDR o per intero ASN (Autonomous System Number) se gli attacchi provengono da un provider specifico.

Un consiglio importante: dopo aver attivato Cloudflare, assicurati di configurare il tuo server per accettare connessioni solo dagli IP di Cloudflare. Altrimenti un attaccante che conosce l’IP reale del tuo server potrebbe bypassare completamente Cloudflare collegandosi direttamente. Su Apache puoi farlo con le direttive Require ip usando gli IP range di Cloudflare pubblicati nella loro documentazione ufficiale. Questo è un passaggio che molti trascurano e che rende inutile tutta la protezione offerta dal CDN.

7. Policy sulle Password e Buone Pratiche Generali

Tutti i meccanismi tecnici del mondo diventano meno efficaci se le password degli utenti sono deboli. “admin123”, “password”, il nome del sito seguito dall’anno corrente: queste sono le prime combinazioni che ogni tool di brute force prova. Ho visto siti compromessi nonostante avessero Wordfence e Cloudflare attivi, semplicemente perché un editor aveva impostato “Mario2023” come password. Ecco le policy che impongo su ogni sito che gestisco e le pratiche quotidiane che raccomando ai miei clienti.

• Password di almeno 16 caratteri che includano lettere maiuscole, minuscole, numeri e caratteri speciali. Utilizzo il generatore di password integrato di WordPress che crea password robuste automaticamente, e insisto affinché gli utenti non le modifichino con qualcosa di più semplice da ricordare.
• Non utilizzare mai “admin” come username. Se il tuo sito ha già un utente “admin”, crea un nuovo account amministratore con un nome utente diverso, trasferisci tutti i contenuti al nuovo account e cancella quello vecchio. L’username “admin” è il primo tentativo di ogni attacco brute force e utilizzarlo dimezza il lavoro dell’attaccante.
• Utilizza un password manager come Bitwarden, 1Password o KeePass per generare e conservare password uniche per ogni sito. Io raccomando Bitwarden ai miei clienti perché è open source, gratuito per uso personale e sincronizza le password tra tutti i dispositivi in modo sicuro.
• Cambia le password regolarmente, almeno ogni 6 mesi per gli account amministratore. Puoi forzare il cambio password con il plugin “Force Password Change” che obbliga gli utenti a cambiare la password al successivo login dopo un periodo prestabilito.
• Controlla regolarmente gli account utente: vai su Utenti → Tutti gli utenti e verifica che non ci siano account sconosciuti o con privilegi elevati non giustificati. Un segno di compromissione è la comparsa di account amministratore che non hai creato tu. Limita il numero di amministratori al minimo indispensabile.
• Mantieni WordPress, temi e plugin aggiornati. Le vulnerabilità note sono un vettore di attacco spesso più efficace del brute force. Attiva gli aggiornamenti automatici per le minor release di WordPress e i plugin di sicurezza. Per i major update, testa prima su un ambiente di staging se ne hai la possibilità.
• Implementa un monitoraggio continuo con plugin come WP Activity Log che registra ogni azione eseguita nella dashboard, inclusi login, modifiche a post, installazione di plugin e cambio di impostazioni. Questo è fondamentale per l’analisi forense nel caso in cui un account venga compromesso nonostante tutte le protezioni attive.

Domande Frequenti sulla Sicurezza Brute Force WordPress

Come capisco se il mio sito WordPress è sotto attacco brute force?

I segnali principali sono: rallentamento improvviso del sito, elevato consumo di CPU sul server, email dal tuo hosting provider che segnala uso eccessivo di risorse e, se hai un plugin come Limit Login Attempts Reloaded, numerose notifiche di blocco IP. Controlla i log di accesso del server cercando richieste POST ripetitive a wp-login.php e xmlrpc.php. Se vedi centinaia di richieste al minuto verso questi URL, sei sotto attacco attivo. Spesso gli attacchi avvengono nelle ore notturne, quindi potresti accorgertene solo al mattino trovando il sito rallentato o irraggiungibile.

Limit Login Attempts Reloaded rallenta il sito?

No, il plugin è estremamente leggero. Utilizza le transient di WordPress per memorizzare i tentativi di login e non effettua query al database durante il caricamento normale delle pagine. Il suo impatto sulle performance è trascurabile, nell’ordine di millisecondi, e in realtà migliora le performance complessive del sito perché riduce il numero di richieste che WordPress deve processare bloccando i bot prima che raggiungano la fase di autenticazione vera e propria. Il vantaggio in termini di sicurezza supera enormemente qualsiasi micro-impatto sulle performance.

Posso usare sia Wordfence che Limit Login Attempts Reloaded?

Tecnicamente sì, ma io lo sconsiglio. Wordfence include già una funzionalità di limitazione dei tentativi di login e usare entrambi i plugin per lo stesso scopo crea conflitti e ridondanza inutile. Se scegli Wordfence, disattiva Limit Login Attempts Reloaded e viceversa. Personalmente preferisco Limit Login Attempts per la sua leggerezza e dedico le risorse risparmiate ad altri strumenti. Wordfence è un ottimo prodotto completo ma è decisamente più pesante in termini di risorse server e può rallentare siti su hosting condivisi.

Il 2FA è davvero necessario se ho già le altre protezioni?

Assolutamente sì. Il 2FA è l’unica protezione che funziona anche nel caso peggiore: quando un attaccante ha già ottenuto username e password corretti, magari attraverso un data breach di un altro servizio dove l’utente ha usato le stesse credenziali. Nessuna delle altre misure protegge in questo scenario specifico. Il 2FA è la tua ultima linea di difesa e per questo lo considero obbligatorio, non opzionale. Costa zero in termini di risorse server e richiede solo 10 secondi in più ad ogni login per digitare il codice dall’app.

Cosa faccio se mi sono bloccato fuori dal sito dopo aver attivato le protezioni?

Accedi via FTP o SSH al server e rinomina la cartella del plugin che ti sta bloccando in /wp-content/plugins/. Ad esempio, rinomina “limit-login-attempts-reloaded” in “limit-login-attempts-reloaded-disabled”. WordPress disattiverà automaticamente il plugin al caricamento successivo. Se il blocco è causato dal 2FA, puoi disabilitarlo allo stesso modo. Se il blocco è a livello .htaccess, modifica il file via FTP rimuovendo le regole che hai aggiunto. Per questo motivo conserva sempre un backup delle credenziali FTP/SSH aggiornate e indipendenti dal pannello WordPress.

Cloudflare gratuito è sufficiente per la protezione brute force?

Per la maggior parte dei siti, il piano gratuito di Cloudflare offre una protezione eccellente contro gli attacchi brute force. Le Custom Rules del WAF, il Bot Fight Mode e la protezione DDoS di base sono incluse gratuitamente. Il piano Pro a 20 dollari al mese aggiunge il WAF gestito con regole specifiche per WordPress e il rate limiting avanzato, che sono utili per siti ad alto traffico o target frequente di attacchi sofisticati. Il piano gratuito combinato con le altre misure descritte in questo articolo è più che sufficiente per la stragrande maggioranza dei siti WordPress.

La Mia Soluzione Definitiva

La sicurezza di un sito WordPress contro gli attacchi brute force non si ottiene con un singolo plugin o una singola configurazione, ma con una strategia multilivello ben implementata. La mia procedura, affinata negli anni, prevede: limitazione dei tentativi di login, URL di login personalizzato e protetto con .htaccess, autenticazione a due fattori obbligatoria per tutti gli amministratori, disabilitazione di XML-RPC, regole firewall Cloudflare e una rigorosa policy sulle password. Ogni livello protegge il sito in modo diverso, e insieme creano una difesa praticamente impenetrabile contro gli attacchi brute force automatizzati e manuali. Implementa tutti i passaggi di questa guida e dormirai sonni molto più tranquilli. Se hai bisogno di assistenza nell’implementazione di queste protezioni sul tuo sito o server, oppure se stai subendo un attacco in corso e hai bisogno di un intervento rapido, contattami direttamente per una consulenza personalizzata e troveremo insieme la soluzione migliore per la tua situazione specifica.