Force brute sur wp-login.php : limiter les tentatives de connexion

Un site WordPress fraîchement mis en ligne, sans aucune promotion ni backlink, commence pourtant à recevoir des tentatives de connexion automatisées dans les heures qui suivent sa publication. Ce n’est jamais du hasard : des robots parcourent en continu les plages d’adresses IP à la recherche d’installations WordPress, et testent systématiquement des combinaisons courantes d’identifiants sur wp-login.php.

Une attaque par force brute réussit rarement en une tentative isolée : c’est le volume qui fait la différence, des milliers d’essais répétés jusqu’à tomber sur la bonne combinaison, souvent facilitée par un mot de passe faible ou réutilisé. Limiter le nombre de tentatives autorisées, à la fois côté applicatif et côté serveur, réduit drastiquement les chances de succès de ce type d’attaque.

Limiter les tentatives au niveau applicatif

WordPress ne bride pas nativement le nombre de tentatives de connexion échouées : c’est un choix délibéré du cœur, qui laisse ce rôle aux extensions ou au code maison, pour éviter d’imposer une politique universelle qui ne conviendrait pas à tous les contextes. Une implémentation simple s’appuie sur le hook wp_login_failed pour compter les échecs par adresse IP dans un transient, et sur authenticate pour bloquer les tentatives suivantes une fois le seuil dépassé :

add_action( 'wp_login_failed', function ( $username ) {
    $ip = $_SERVER['REMOTE_ADDR'] ?? '';
    $cle = 'echecs_connexion_' . md5( $ip );
    $echecs = (int) get_transient( $cle );
    set_transient( $cle, $echecs + 1, 15 * MINUTE_IN_SECONDS );
} );

add_filter( 'authenticate', function ( $user ) {
    $ip = $_SERVER['REMOTE_ADDR'] ?? '';
    $echecs = (int) get_transient( 'echecs_connexion_' . md5( $ip ) );
    if ( $echecs >= 5 ) {
        return new WP_Error( 'trop_de_tentatives', __( 'Trop de tentatives, réessayez plus tard.', 'mon-site' ) );
    }
    return $user;
}, 30 );

Ce mécanisme reste volontairement simple : il illustre le principe, mais une extension éprouvée gère en plus les cas de proxy, les listes blanches d’IP de confiance et le nettoyage automatique des compteurs.

Ajouter une limitation côté nginx

La limitation applicative a un coût : chaque tentative, même bloquée, déclenche tout de même le chargement complet de WordPress avant d’être rejetée. Une règle limit_req posée au niveau de nginx filtre une partie du trafic avant même qu’il n’atteigne PHP :

limit_req_zone $binary_remote_addr zone=connexion:10m rate=1r/s;

location = /wp-login.php {
    limit_req zone=connexion burst=3 nodelay;
    fastcgi_pass unix:/run/php/php-fpm.sock;
    include fastcgi_params;
}

Cette configuration autorise en moyenne une requête par seconde et par adresse IP sur wp-login.php, avec une marge de trois requêtes en rafale. Au-delà, nginx répond directement avec un code 503, sans jamais solliciter PHP ni la base de données.

Bloquer les IP les plus insistantes

Au-delà de la limitation de fréquence, certaines adresses reviennent de façon répétée sur plusieurs jours. Un examen régulier des journaux d’accès permet de les identifier :

grep "POST /wp-login.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Les adresses qui cumulent plusieurs centaines de tentatives en quelques heures sont de bonnes candidates à un blocage explicite au niveau du pare-feu ou du serveur, en complément de la limitation de fréquence déjà en place.

Éviter les faux positifs

• Un compteur basé uniquement sur l’adresse IP peut pénaliser plusieurs utilisateurs légitimes partageant la même IP (bureau, réseau d’entreprise) : prévoir une liste blanche pour les IP connues de l’équipe.
• Une durée de blocage trop longue transforme une simple faute de frappe en mise à l’écart prolongée : quinze à trente minutes suffisent généralement.
• Sur un site derrière un proxy ou un CDN, s’assurer que l’adresse IP utilisée pour le comptage est la vraie IP du visiteur (via l’en-tête X-Forwarded-For correctement configuré), sous peine de compter toutes les requêtes sous une seule IP.

Une limitation de tentatives mal calibrée finit par gêner l’équipe elle-même plus que les attaquants, qui changent d’adresse IP sans effort.

En résumé

Combiner une limitation applicative sur wp-login.php et une règle de débit côté nginx réduit considérablement la fenêtre d’exposition d’un site face aux attaques par force brute, sans nécessiter d’outil externe supplémentaire. Cette double couche reste complémentaire d’un mot de passe robuste et, idéalement, d’une authentification à deux facteurs sur les comptes à privilèges.