Limitare Login Attempts WordPress per Agenzie: Guida Completa [2026]

Limitare i login attempts su WordPress è la prima difesa contro attacchi brute force che, secondo i dati di Wordfence, generano oltre 6,4 miliardi di tentativi al mese sulla rete WordPress. Se gestisci più siti per clienti, non configurare questa protezione significa lasciare la porta aperta a bot automatizzati 24 ore su 24.

Nella nostra esperienza di gestione di decine di siti WordPress client, abbiamo testato ogni approccio: dai plugin gratuiti alle regole server-side, dal codice in functions.php ai WAF gestiti. Questa guida raccoglie cosa funziona davvero nel 2026, con configurazioni testate su siti in produzione.

TL;DR — Cosa trovi in questa guida

• Perché limitare i login attempts è non negoziabile su ogni sito WordPress
• I 4 plugin più efficaci per limitare i tentativi di login (confronto reale)
• Configurazione di Limit Login Attempts Reloaded: impostazioni consigliate
• Protezione server-side con .htaccess e fail2ban (zero plugin)
• Strategia multi-layer per agenzie: login protection su 20+ siti
• FAQ con risposte dirette per featured snippets e AI search

Cos’è la limitazione dei login attempts su WordPress

Limitare i login attempts significa bloccare o rallentare i tentativi di accesso falliti da un indirizzo IP specifico dopo un numero prestabilito di errori. È un controllo di sicurezza che rende gli attacchi brute force — quelli che provano milioni di combinazioni di username e password — lenti, costosi e inefficaci.

WordPress, di default, non ha nessun limite sui tentativi di login falliti. Un bot può provare 1000 password al minuto su /wp-login.php senza che il sistema reagisca. Questa è una delle vulnerabilità più sfruttate dell’ecosistema WordPress: non è un bug, è un’assenza di difesa.

Secondo il report State of Brute Force Attacks in WordPress: 2025 di Limit Login Attempts Reloaded, gli attacchi brute force per dominio sono aumentati del 120% nel 2024, con un ulteriore surge previsto nel 2026. I bot ora usano AI per generare combinazioni più intelligenti, riducendo il numero di tentativi necessari.

Perché limitare i login attempts è obbligatorio nel 2026

I numeri parlano chiaro. Ecco i dati più recenti dal landscape della sicurezza WordPress:

Per un’agenzia che gestisce 20+ siti, ogni sito senza limitazione dei login è un punto di ingresso potenziale. Un singolo sito compromesso può diventare la testa di ponte per attacchi verso gli altri — soprattutto se usi le stesse credenziali admin su più installazioni.

I migliori plugin per limitare i login attempts su WordPress

Abbiamo testato i 4 plugin più diffusi su siti WordPress reali in produzione. Ecco il confronto tecnico, non quello che leggi nelle recensioni ma quello che osservi dopo 30 giorni di traffico reale e attacchi bot.

Il nostro consiglio: Limit Login Attempts Reloaded

Per agenzie che gestiscono multi-sito, Limit Login Attempts Reloaded (LLAR) è la scelta migliore per tre motivi:

1. Impatto performance minimo: il plugin pesa meno di 200KB e non esegue scansioni file in background come Wordfence
2. Network mode: la versione Premium crea una rete condivisa di IP bloccati tra tutti i siti gestiti, bloccando proattivamente gli attaccanti prima ancora che provino il login
3. Configurazione granulare: puoi impostare soglie diverse per ruolo utente (più tollerante per admin, più aggressivo per subscriber)

Secondo il report LLAR 2025, i siti con la versione Premium bloccano il 97% degli attacchi brute force, con un miglioramento del 20% di efficienza anno su anno.

Configurazione di Limit Login Attempts Reloaded: impostazioni consigliate

Dopo aver installato LLAR su oltre 30 siti client, queste sono le impostazioni che consigliamo per il 90% dei casi:

Impostazioni lockout (tab Settings → Lockout)

Configurazione via codice (alternativa senza plugin)

Se vuoi limitare i login attempts senza installare un plugin — ad esempio su siti dove minimizzare le dipendenze è prioritario — puoi usare questo snippet nel file functions.php del tuo child theme:

// Limitare login attempts WordPress senza plugin
// Aggiungere a functions.php del child theme

add_action( 'wp_login_failed', 'ap_track_failed_login' );

function ap_track_failed_login( $username ) {
    $ip = ap_get_client_ip();
    $transient_key = 'ap_login_fail_' . md5( $ip );
    $attempts = get_transient( $transient_key );

    if ( false === $attempts ) {
        $attempts = 0;
    }

    $attempts++;
    set_transient( $transient_key, $attempts, 20 * MINUTE_IN_SECONDS );

    // Dopo 4 tentativi falliti, blocca per 20 minuti
    if ( $attempts >= 4 ) {
        $block_key = 'ap_login_blocked_' . md5( $ip );
        set_transient( $block_key, true, 20 * MINUTE_IN_SECONDS );
        error_log( "WordPress: IP {$ip} bloccato dopo {$attempts} tentativi di login falliti" );
    }
}

add_filter( 'authenticate', 'ap_check_login_block', 30, 3 );

function ap_check_login_block( $user, $username, $password ) {
    $ip = ap_get_client_ip();
    $block_key = 'ap_login_blocked_' . md5( $ip );

    if ( get_transient( $block_key ) ) {
        return new WP_Error(
            'too_many_attempts',
            'Troppi tentativi di login falliti. Riprova tra 20 minuti.'
        );
    }

    return $user;
}

function ap_get_client_ip() {
    $ip_keys = [ 'HTTP_CF_CONNECTING_IP', 'HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR' ];
    foreach ( $ip_keys as $key ) {
        if ( ! empty( $_SERVER[ $key ] ) ) {
            $ip = trim( explode( ',', $_SERVER[ $key ] )[0] );
            if ( filter_var( $ip, FILTER_VALIDATE_IP ) ) {
                return $ip;
            }
        }
    }
    return '0.0.0.0';
}

Nota: questo snippet usa i transient di WordPress, che si basano sul database. Per siti ad alto traffico, preferisci una soluzione con Redis o object cache persistente per evitare query DB ad ogni tentativo.

Protezione server-side: .htaccess e fail2ban

La protezione a livello di applicazione (plugin o codice PHP) è efficace ma ha un limite: il server processa comunque la richiesta. Ogni tentativo di login consuma risorse PHP e MySQL. Su un sito sotto attacco intensivo, questo può causare un Denial of Service de facto.

La protezione server-side blocca le richieste prima che raggiungano WordPress. Più efficiente, più sicura, ma richiede accesso al server.

Bloccare wp-login.php via .htaccess (Apache/LiteSpeed)

# Limitare accessi a wp-login.php via .htaccess
# Protezione brute force a livello server

<Files wp-login.php>
    # Limite di 10 richieste al minuto per IP
    <IfModule mod_limitipconn.c>
        MaxConnPerIP 1
    </IfModule>

    # Blocca paesi specifici (opzionale)
    # Richiede mod_geoip o GeoIP2
    # SetEnvIf GEOIP_COUNTRY_CODE CN DenyCountry
    # SetEnvIf GEOIP_COUNTRY_CODE RU DenyCountry
    # Deny from env=DenyCountry
</Files>

# Protezione XML-RPC (vetta di accesso per brute force)
<Files xmlrpc.php>
    Order Deny,Allow
    # Allow da IP specifici (es. ufficio agenzia)
    # Allow from 192.168.1.0/24
    Deny from all
</Files>

Protezione con fail2ban (Nginx/Apache su VPS)

Per agenzie su VPS o server dedicati, fail2ban è la soluzione più robusta. Monitora i log di WordPress e banna automaticamente gli IP al firewall del sistema operativo (iptables/nftables), prima ancora che la richiesta arrivi a PHP.

Configurazione di esempio su Debian/Ubuntu:

# /etc/fail2ban/filter.d/wp-login.conf
[Definition]
failregex = ^.*POST.*wp-login.php.*HTTP.*$
            ^.*POST.*xmlrpc.php.*HTTP.*$
ignoreregex =

# /etc/fail2ban/jail.d/wp-login.conf
[wp-login]
enabled = true
filter = wp-login
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 300
bantime = 3600
banaction = nftables-multiport
port = http,https

Questa configurazione banna l’IP per 1 ora dopo 5 tentativi di accesso a wp-login.php o xmlrpc.php entro 5 minuti. Il blocco avviene a livello di firewall: zero consumo PHP, zero query MySQL.

Protezione XML-RPC: il backdoor spesso dimenticato

Quando limiti i login attempts su WordPress, non puoi ignorare XML-RPC. Il file xmlrpc.php espone un’API che permette di effettuare login programmatici — e i bot lo usano massivamente per brute force perché non rispetta i limiti dei plugin che agiscono solo su wp-login.php.

XML-RPC supporta il metodo system.multicall, che permette di inviare centinaia di tentativi di autenticazione in una singola richiesta HTTP. Un plugin che limita a 4 tentativi su wp-login.php è completamente inutile se l’attaccante manda 500 password in una chiamata XML-RPC.

Soluzioni:

1. Disabilitare XML-RPC completamente se non lo usi (raccomandato per il 95% dei siti):

// Disabilitare XML-RPC in functions.php
add_filter( 'xmlrpc_enabled', '__return_false' );

// Rimuovere l'header di scoperta XML-RPC
remove_action( 'wp_head', 'rsd_link' );

// Disabilitare pingback (vettore di attacco DDoS)
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Oppure a livello server:

# Disabilitare XML-RPC via .htaccess
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

2. Limitare XML-RPC a IP specifici se lo usi per app mobile o pubblicazione remota:

# Permittere XML-RPC solo da IP autorizzati
<Files xmlrpc.php>
    Order Deny,Allow
    Allow from 192.168.1.50    # IP ufficio
    Allow from 203.0.113.42    # IP app personalizzata
    Deny from all
</Files>

Strategia multi-layer per agenzie: login protection su 20+ siti

Gestire la sicurezza del login su molti siti richiede un approccio diverso dal gestirne uno. La regola è: automatizzare a livello server, centralizzare a livello di management.

Livello 1: Server-side (obbligatorio)

Su ogni server VPS/cloud, configura fail2ban o le regole del firewall. Questo è il primo filtro — blocca gli attacchi prima che raggiungano WordPress. Nessun plugin può competere con un ban a livello di iptables/nftables.

Livello 2: Plugin WordPress (standard)

Su ogni singolo sito, installa Limit Login Attempts Reloaded con le impostazioni standard descritte sopra. Questo gestisce i casi che il firewall di sistema non copre (es. attacchi distribuiti da IP diversi).

Livello 3: Centralizzazione (il vero vantaggio per agenzie)

La versione Premium di LLAR offre il network mode: quando un IP viene bloccato su un sito, viene automaticamente bloccato su tutti i siti della tua rete. Questo riduce il tempo di risposta agli attacchi distribuiti da ore a secondi.

In alternativa, se usi AgencyPilot per la gestione centralizzata, puoi monitorare i log di login falliti su tutti i siti dalla stessa dashboard, identificare pattern di attacco coordinati e applicare blocklist su tutti i siti contemporaneamente.

Checklist implementazione per agenzie

Autenticazione a due fattori: il complemento obbligatorio

Limitare i login attempts ferma i brute force classici, ma non protegge da attacchi più sofisticati come credential stuffing — dove l’attaccante usa password reali rubicate da altri breach. Nel 2026, con database di credenziali rubate che circolano liberamente, la password sola non basta più.

L’autenticazione a due fattori (2FA) su WordPress è il complemento naturale alla limitazione dei login. Anche se un attaccante indovina la password, non può accedere senza il secondo fattore.

Le opzioni migliori per implementare 2FA su WordPress nel 2026:

• WP 2FA: gratuito, supporto TOTP e email, integrazione con ruoli WordPress
• Wordfence 2FA: incluso nella versione gratuita, ma richiede l’installazione di Wordfence completo
• LLAR Premium 2FA: integrato nel plugin di limitazione login, niente dipendenze aggiuntive

Configurazione consigliata: obbliga 2FA per tutti gli utenti con ruolo Administrator e Editor. Lascia facoltativo per autori e contributor. Questo riduce la superficie di attacco senza creare attrito per utenti a basso rischio.

Monitoraggio: come sapere se il tuo sito è sotto attacco

Limitare i login attempts non è un set-and-forget. Devi monitorare i log per identificare:

• Pattern di attacco coordinati: molti IP che provano login nello stesso momento (attacco distribuito)
• Username targeting: se i bot provano sempre lo stesso username, probabilmente è quello dell’admin. Cambialo.
• Timing degli attacchi: secondo il report LLAR, il Q4 è il periodo più attivo (allineato al picco e-commerce). Aumenta il monitoraggio in questo periodo.

Se gestisci i siti con strumenti di gestione centralizzata, configura alert via email o Slack quando i lockout superano una soglia (es. più di 10 IP bloccati in un’ora = possibile attacco coordinato).

FAQ — Domande frequenti su limitare login attempts WordPress

Quanti tentativi di login falliti dovrei permettere su WordPress?

Il numero ideale è 4 tentativi prima del primo lockout. Questo dà margine a utenti legittimi che sbagliano password (o che hanno la capslock attiva) ma è troppo basso per un brute force efficace. Dopo 3 lockout consecutivi (12 tentativi totali), l’IP dovrebbe essere bloccato per 24 ore.

Limitare i login attempts rallenta il sito WordPress?

No, se usi un plugin leggero come Limit Login Attempts Reloaded. Il plugin pesa meno di 200KB e agisce solo sull’endpoint di login, non influenzando il frontend. Soluzioni server-side come fail2ban hanno impatto zero sulle performance di WordPress perché il blocco avviene a livello di firewall, prima che la richiesta raggiunga PHP.

WordPress ha un limite nativo sui tentativi di login?

No. WordPress core non ha nessun limite sui tentativi di login falliti. Questo è una delle criticità più note della piattaforma. Un bot può tentare infiniti login senza che WordPress reagisca. Per questo motivo, l’installazione di un plugin di limitazione o una regola server-side è considerata obbligatorio su ogni sito in produzione.

Qual è il miglior plugin per limitare i login attempts su WordPress?

Per la maggior parte dei siti, Limit Login Attempts Reloaded è la scelta migliore: leggero, 3+ milioni di installazioni attive, configurazione semplice e network mode per agenzie. Se hai già Wordfence installato per altri motivi, il suo modulo di login security è valido ma più pesante. Per siti su VPS, la soluzione ottimale è fail2ban a livello server + LLAR a livello WordPress.

XML-RPC bypassa i limiti sui login attempts?

Sì. I plugin che limitano i tentativi di login su wp-login.php non sempre coprono xmlrpc.php. XML-RPC supporta il metodo system.multicall che permette centinaia di tentativi di autenticazione in una singola richiesta HTTP. Per questo è fondamentale disabilitare XML-RPC se non lo usi o applicare le stesse protezioni anche a quel file.

Come gestire la limitazione dei login su 20+ siti WordPress?

Usa un approccio multi-layer: fail2ban a livello server su ogni VPS, Limit Login Attempts Reloaded su ogni sito, e una dashboard centralizzata per monitorare i log. La versione Premium di LLAR offre il network mode che condivide le blocklist tra tutti i siti. In alternativa, strumenti come AgencyPilot permettono di gestire e monitorare la sicurezza del login da un unico pannello.