{"id":731,"date":"2026-02-09T09:00:00","date_gmt":"2026-02-09T08:00:00","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/sicurezza-wordpress-brute-force\/"},"modified":"2026-02-18T18:04:21","modified_gmt":"2026-02-18T17:04:21","slug":"sicurezza-wordpress-brute-force","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/sicurezza-wordpress-brute-force\/","title":{"rendered":"Come Metto in Sicurezza WordPress da Attacchi Brute Force: La Mia Procedura"},"content":{"rendered":"

Se gestisci siti WordPress da qualche anno come faccio io, sai benissimo che gli attacchi brute force su wp-login.php<\/strong> sono all’ordine del giorno. Non \u00e8 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\u00e9 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.<\/p>\n

La mia filosofia di sicurezza si basa su un principio fondamentale: la difesa in profondit\u00e0<\/strong>. Non mi affido mai a un singolo meccanismo di protezione, ma creo pi\u00f9 livelli di sicurezza sovrapposti, in modo che se uno fallisce, gli altri continuino a proteggere il sito. Questo approccio richiede un po’ pi\u00f9 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 \u00e8 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\u00e0. 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.<\/p>\n

1. Identificare gli Attacchi Brute Force nei Log del Server<\/h2>\n

Il primo passo della mia procedura \u00e8 sempre quello di analizzare i log del server<\/strong> per capire l’entit\u00e0 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\u00e9 contengono informazioni preziosissime su cosa sta succedendo sul server. Ecco come procedo per identificare i tentativi di brute force in corso.<\/p>\n

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

    Un segnale chiaro di attacco brute force \u00e8 vedere centinaia di richieste POST a wp-login.php con codice di risposta 200<\/strong> (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\u00e0 del sito.<\/p>\n

    2. Limitare i Tentativi di Login con Plugin Dedicati<\/h2>\n

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

      \n
    1. Installa il plugin “Limit Login Attempts Reloaded”<\/strong> dalla dashboard WordPress: vai su Plugin \u2192 Aggiungi Nuovo \u2192 cerca “Limit Login Attempts Reloaded” \u2192 Installa e Attiva. Questo plugin \u00e8 gratuito, leggero, ben mantenuto e utilizzato da oltre due milioni di siti WordPress. Io lo preferisco ad alternative pi\u00f9 pesanti come Wordfence per questo specifico scopo perch\u00e9 ha un impatto minimo sulle performance.<\/li>\n
    2. Configura i parametri di blocco<\/strong> accedendo a Impostazioni \u2192 Limit Login Attempts. Io utilizzo questi valori: 4 tentativi consentiti<\/b>, blocco per 20 minuti<\/b> dopo il superamento dei tentativi, 4 blocchi<\/b> prima di un blocco esteso di 24 ore<\/b>. Questi valori sono il risultato di anni di esperienza e bilanciano bene la sicurezza con la possibilit\u00e0 che un utente legittimo sbagli la password qualche volta.<\/li>\n
    3. Abilita le notifiche email<\/strong> 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\u00f9 persistenti.<\/li>\n
    4. Aggiungi alla whitelist il tuo IP<\/strong> (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.<\/li>\n
    5. Verifica i log del plugin<\/strong> 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.<\/li>\n<\/ol>\n

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

      3. Rinominare wp-login.php e Proteggere con .htaccess<\/h2>\n

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

        \n
      1. Installa il plugin “WPS Hide Login”<\/strong>, che \u00e8 leggero, gratuito e utilizzato da oltre un milione di siti. Dopo l’attivazione, vai su Impostazioni \u2192 WPS Hide Login e cambia l’URL di login da \/wp-login.php<\/b> a qualcosa di personalizzato, ad esempio \/accesso-riservato<\/b> o \/mio-login-2024<\/b>. Evita URL troppo ovvi come \/login o \/admin. Annota il nuovo URL e comunicalo a tutti gli utenti del sito.<\/li>\n
      2. Configura la pagina di redirect<\/strong>: quando qualcuno prova ad accedere a \/wp-login.php, il plugin pu\u00f2 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.<\/li>\n
      3. Aggiungi protezione .htaccess aggiuntiva<\/strong> alla directory wp-admin. Apri il file .htaccess<\/b> nella root del sito e aggiungi questa regola per bloccare l’accesso diretto a wp-login.php anche bypassando il plugin:<\/li>\n<\/ol>\n

        Ecco il codice .htaccess<\/b> che utilizzo per proteggere la pagina di login con autenticazione HTTP aggiuntiva:<\/p>\n

        \n# Protezione wp-login.php con password HTTP\n<Files wp-login.php>\nAuthType Basic\nAuthName \"Area Riservata\"\nAuthUserFile \/home\/tuoutente\/.htpasswd\nRequire valid-user\n<\/Files>\n<\/pre>\n
        Per creare il file .htpasswd<\/b>, esegui da terminale: htpasswd -c \/home\/tuoutente\/.htpasswd nomeutente<\/b> e inserisci la password quando richiesto. Il percorso del file .htpasswd deve essere fuori dalla document root<\/strong> 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.<\/p>\n
        Un altro blocco .htaccess molto utile \u00e8 limitare l’accesso al pannello di amministrazione solo a determinati indirizzi IP:<\/p>\n
        \n# Limita accesso wp-admin per IP\n<IfModule mod_rewrite.c>\nRewriteEngine On\nRewriteCond %{REQUEST_URI} ^\/wp-admin [NC]\nRewriteCond %{REMOTE_ADDR} !^123.456.789.0$\nRewriteCond %{REMOTE_ADDR} !^111.222.333.444$\nRewriteRule ^(.*)$ - [F,L]\n<\/IfModule>\n<\/pre>\n
        Sostituisci gli indirizzi IP con quelli da cui accedi normalmente. Se lavori da IP dinamico, questa soluzione \u00e8 meno pratica, ma resta utilissima per siti gestiti sempre dallo stesso ufficio con IP statico.<\/p>\n
        4. Implementare l’Autenticazione a Due Fattori (2FA)<\/h2>\n
        L’autenticazione a due fattori \u00e8 forse la singola misura pi\u00f9 importante<\/strong> 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\u00e0 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.<\/p>\n
          \n
        1. Installa il plugin “WP 2FA – Two-factor Authentication”<\/strong> dalla directory ufficiale di WordPress. Questo plugin \u00e8 sviluppato da WP White Security, un team specializzato in sicurezza WordPress, ed \u00e8 la soluzione che preferisco perch\u00e9 offre un ottimo equilibrio tra funzionalit\u00e0 e semplicit\u00e0 d’uso. La versione gratuita \u00e8 pi\u00f9 che sufficiente per la maggior parte dei siti.<\/li>\n
        2. Attiva il 2FA per tutti gli amministratori<\/strong>: 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\u00f9 completa, soprattutto su siti multi-autore.<\/li>\n
        3. Scegli il metodo TOTP<\/strong> (Time-based One-Time Password) come metodo primario. Funziona con app gratuite come Google Authenticator<\/b>, Authy<\/b> o Microsoft Authenticator<\/b>. Io preferisco Authy perch\u00e9 permette il backup cloud dei codici, quindi se perdi il telefono non resti tagliato fuori da tutti i tuoi siti.<\/li>\n
        4. Configura un metodo di backup<\/strong>: abilita i codici di backup monouso che l’utente pu\u00f2 stampare e conservare in un luogo sicuro. Ogni utente riceve tipicamente 10 codici di backup, ognuno utilizzabile una sola volta. Questo \u00e8 fondamentale per evitare lockout nel caso in cui il telefono con l’app di autenticazione non sia disponibile.<\/li>\n
        5. Imposta un periodo di grazia<\/strong> 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.<\/li>\n
        6. Testa il funzionamento<\/strong> 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.<\/li>\n<\/ol>\n
          Un’alternativa valida come plugin 2FA \u00e8 miniOrange Google Authenticator<\/strong>, che offre funzionalit\u00e0 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\u00ec proteggi sia l’accesso WordPress che quello al server stesso con un approccio unificato alla sicurezza.<\/p>\n
          5. Disabilitare XML-RPC e Proteggere Endpoint Vulnerabili<\/h2>\n
          Il file xmlrpc.php<\/strong> \u00e8 uno dei vettori di attacco pi\u00f9 sfruttati dopo wp-login.php. Originariamente progettato per consentire la pubblicazione remota di articoli e la comunicazione tra siti WordPress (pingback e trackback), oggi \u00e8 utilizzato principalmente dagli attaccanti per effettuare brute force amplificati. Attraverso il metodo system.multicall<\/b>, un singolo request HTTP pu\u00f2 testare centinaia di combinazioni di credenziali simultaneamente, rendendo gli attacchi molto pi\u00f9 efficienti e difficili da rilevare. Nella maggior parte dei siti che gestisco, XML-RPC non serve e pu\u00f2 essere disabilitato completamente senza alcuna conseguenza negativa.<\/p>\n
            \n
          1. Verifica se XML-RPC \u00e8 necessario<\/strong>: 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\u00e0 di XML-RPC in modo pi\u00f9 sicuro e moderno.<\/li>\n
          2. Disabilita XML-RPC via .htaccess<\/strong> aggiungendo questo blocco al file nella root del sito:<\/li>\n<\/ol>\n
            \n# Blocca completamente xmlrpc.php\n<Files xmlrpc.php>\nOrder Deny,Allow\nDeny from all\n<\/Files>\n<\/pre>\n
              \n
            1. In alternativa, usa il plugin “Disable XML-RPC”<\/strong> se preferisci una soluzione gestibile dalla dashboard. Il plugin aggiunge semplicemente un filtro WordPress che disabilita tutte le funzionalit\u00e0 XML-RPC. \u00c8 la soluzione meno invasiva e pi\u00f9 facilmente reversibile.<\/li>\n
            2. Proteggi anche wp-cron.php<\/strong> da accessi esterni eccessivi. Sebbene non sia un vettore di brute force, un accesso massivo a wp-cron.php pu\u00f2 sovraccaricare il server. Disabilita il cron interno di WordPress aggiungendo in wp-config.php<\/b>: define(‘DISABLE_WP_CRON’, true);<\/b> e configura un cron di sistema: *\/15 * * * * wget -q -O – https:\/\/tuodominio.it\/wp-cron.php?doing_wp_cron > \/dev\/null 2>&1<\/b><\/li>\n
            3. Blocca l’enumerazione degli utenti<\/strong> aggiungendo in .htaccess:<\/li>\n<\/ol>\n
              \n# Blocca enumerazione utenti via REST API e parametro author\nRewriteCond %{QUERY_STRING} ^author=([0-9]+) [NC]\nRewriteRule .* - [F,L]\n\n# Blocca accesso diretto alla REST API users endpoint per utenti non autenticati\n<IfModule mod_rewrite.c>\nRewriteEngine On\nRewriteCond %{REQUEST_URI} ^\/wp-json\/wp\/v2\/users [NC]\nRewriteCond %{HTTP_COOKIE} !wordpress_logged_in\nRewriteRule .* - [F,L]\n<\/IfModule>\n<\/pre>\n
              L’enumerazione degli utenti \u00e8 spesso il primo passo di un attacco brute force: l’attaccante cerca di scoprire gli username validi visitando \/?author=1<\/b>, \/?author=2<\/b> e cos\u00ec 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\u00f9 difficile.<\/p>\n
              6. Configurare Cloudflare e Regole Firewall Avanzate<\/h2>\n
              L’ultimo livello della mia strategia di difesa \u00e8 Cloudflare<\/strong>, che agisce come primo bastione filtrando il traffico malevolo prima ancora che raggiunga il server. Anche il piano gratuito di Cloudflare offre funzionalit\u00e0 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 \u00e8 particolarmente importante su hosting condivisi dove le risorse sono limitate e un attacco brute force sostenuto pu\u00f2 far sospendere il tuo account dall’hosting provider.<\/p>\n
                \n
              1. Attiva la modalit\u00e0 “Under Attack”<\/strong> temporaneamente se sei sotto un attacco massiccio in corso. Questa modalit\u00e0 presenta un challenge JavaScript a tutti i visitatori prima di farli passare, bloccando efficacemente i bot automatizzati. Non lasciarla attiva permanentemente perch\u00e9 rallenta l’accesso per i visitatori legittimi con un’attesa di circa 5 secondi.<\/li>\n
              2. Crea una regola WAF personalizzata<\/strong> per proteggere wp-login.php. Nella dashboard Cloudflare vai su Security \u2192 WAF \u2192 Custom Rules e crea una regola con queste condizioni: URI Path contains “\/wp-login.php”<\/b> AND IP Source Address is not in {il tuo IP}<\/b> \u2192 Action: Managed Challenge<\/b>. Questo presenta un captcha a chiunque non sia tu prima di accedere alla pagina di login.<\/li>\n
              3. Crea una regola per bloccare xmlrpc.php<\/strong>: URI Path contains “\/xmlrpc.php”<\/b> \u2192 Action: Block<\/b>. Questo blocca tutte le richieste a XML-RPC a livello di Cloudflare, senza nemmeno raggiungere il tuo server.<\/li>\n
              4. Configura il Rate Limiting<\/strong>: crea una regola che limita le richieste alla pagina di login. Imposta un limite di 5 richieste per minuto<\/b> per IP verso URL che contengono “wp-login”. Quando il limite viene superato, Cloudflare blocca l’IP per un periodo configurabile. Questa funzionalit\u00e0 \u00e8 disponibile anche nel piano gratuito con alcune limitazioni.<\/li>\n
              5. Abilita il Bot Fight Mode<\/strong> 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.<\/li>\n
              6. Configura le IP Access Rules<\/strong> per bloccare permanentemente interi range di IP che attaccano ripetutamente. Vai su Security \u2192 WAF \u2192 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.<\/li>\n<\/ol>\n
                Un consiglio importante: dopo aver attivato Cloudflare, assicurati di configurare il tuo server per accettare connessioni solo dagli IP di Cloudflare<\/strong>. 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<\/b> usando gli IP range di Cloudflare pubblicati nella loro documentazione ufficiale. Questo \u00e8 un passaggio che molti trascurano e che rende inutile tutta la protezione offerta dal CDN.<\/p>\n
                7. Policy sulle Password e Buone Pratiche Generali<\/h2>\n
                Tutti i meccanismi tecnici del mondo diventano meno efficaci se le password degli utenti sono deboli<\/strong>. “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\u00e9 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.<\/p>\n