En bref : une protection efficace contre la force brute pour une connexion se compose de plusieurs couches : authentification à deux facteurs pour tous les admins, un frein aux tentatives de connexion dans le serveur web, des blocages automatiques au niveau du réseau et un stockage sûr des mots de passe dans le code. Lorsque c'est possible, la zone d'administration n'est en outre accessible que depuis des réseaux connus.
Comment se déroulent les attaques par force brute sur les connexions
Toute page de connexion accessible publiquement est tôt ou tard attaquée de façon automatisée. Cela concerne les connexions de CMS, les back-ends de boutique, les panneaux d'hébergement, le webmail et SSH. Pour cela, les attaquants n'ont pas besoin de savoir à qui appartient le site ; leurs outils parcourent Internet à la recherche d'adresses de connexion connues.
Trois variantes sont répandues. Dans la force brute classique, de nombreux mots de passe sont essayés contre un compte. Dans le password spraying, un mot de passe courant est testé contre de nombreux comptes afin de contourner les blocages. Dans le credential stuffing, on utilise des identifiants volés auprès d'autres services.
Pour la direction et les propriétaires, la situation se résume simplement : un compte administrateur repris est aussi dangereux qu'une faille de sécurité dans le serveur. Qui est admin peut installer des extensions, modifier du code et exporter des données.
De telles attaques se reconnaissent à une accumulation de connexions échouées, à des requêtes POST vers l'adresse de connexion depuis de nombreuses adresses IP différentes et à des tentatives de connexion avec des noms d'utilisateur comme « admin » ou des noms tirés des mentions légales. Une charge serveur nettement plus élevée à des heures inhabituelles peut aussi l'indiquer, car chaque connexion coûte du temps de calcul pour la vérification du mot de passe.
Protection contre la force brute à la connexion : les mesures les plus efficaces
Toutes les mesures ne conviennent pas à tous les systèmes. L'ordre suivant a fait ses preuves, car les premiers points associent le plus d'effet à peu d'efforts :
- Authentification à deux facteurs pour tous les comptes disposant de droits d'administrateur. Même un mot de passe deviné ne suffit alors pas. Détails dans le guide Authentification à deux facteurs pour les accès administrateur.
- Mots de passe uniques et longs issus d'un gestionnaire de mots de passe, pas de comptes partagés.
- Limitation de débit dans le serveur web, afin que seules quelques tentatives par minute soient possibles par adresse.
- Blocages automatiques des adresses répétitivement suspectes au niveau du réseau, par exemple avec Fail2ban.
- Réduire la zone d'administration : accès uniquement depuis le réseau de l'entreprise ou par VPN, désactiver les interfaces inutiles.
- Messages d'erreur uniformes qui ne révèlent pas si le nom d'utilisateur existe.
- Surveillance des connexions échouées et notification en cas d'anomalies.
Limitation de débit dans le serveur web
Avec Nginx, le nombre de requêtes vers une adresse de connexion peut être limité par adresse IP. L'exemple montre une page de connexion WordPress ; adaptez le chemin et la transmission à PHP à votre système.
# dans le bloc http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
# dans le bloc server
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
limit_req_status 429;
# inclure ici la transmission PHP habituelle de votre serveur
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
Sous Apache, la restriction de la zone d'administration à des adresses connues offre une protection simple et efficace :
<Location "/admin">
Require ip 192.0.2.0/24
</Location>
L'adresse 192.0.2.0/24 est un espace réservé issu de la plage de documentation ; indiquez votre réseau d'entreprise ou l'adresse de votre VPN. Si votre site se trouve derrière un proxy ou un CDN, le serveur doit connaître la véritable adresse du visiteur, sinon la règle ne fonctionne pas comme souhaité.
Fail2ban et blocages au niveau du réseau
Fail2ban lit des fichiers journaux et bloque dans le pare-feu, pour une durée définie, les adresses qui se font remarquer à répétition. Pour la limitation de débit de Nginx, Fail2ban fournit déjà un filtre approprié :
# /etc/fail2ban/jail.local
[nginx-limit-req]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 10m
bantime = 1h
[sshd]
enabled = true
maxretry = 5
bantime = 1h
Après le redémarrage, vérifiez avec fail2ban-client status que les jails sont actives. Veillez à exclure vos propres adresses fixes via ignoreip afin de ne pas vous verrouiller vous-même. Des filtres dédiés sont possibles pour les pages de connexion de certains CMS, mais ils doivent correspondre au format réel du journal et être testés au préalable.
Si un CDN ou un proxy se trouve devant le serveur, Fail2ban ne voit, sans autre réglage, que leurs adresses. Un blocage toucherait alors tous les visiteurs. Dans ce cas, le serveur web doit reprendre la véritable adresse du visiteur à partir de l'en-tête du service placé en amont, et il vaut mieux définir les blocages directement chez le CDN.
Les blocages au niveau du réseau sont un outil contre la masse, pas contre les attaques ciblées. Les attaques distribuées depuis de très nombreuses adresses avec peu de tentatives par adresse passent sous n'importe quel seuil. C'est pourquoi le second facteur reste la couche la plus importante, et Fail2ban réduit surtout la charge et le bruit dans les journaux.
Stocker correctement les mots de passe dans son propre logiciel
Qui programme ses propres connexions ne devrait jamais stocker les mots de passe en clair ni avec des fonctions de hachage rapides comme MD5 ou SHA-1. PHP fournit avec password_hash() une solution sûre qui gère automatiquement le sel et la méthode.
<?php
declare(strict_types=1);
// À l'inscription ou lors d'un changement de mot de passe
$hash = password_hash($passwort, PASSWORD_DEFAULT);
// À la connexion
if (password_verify($eingabe, $hashAusDatenbank)) {
if (password_needs_rehash($hashAusDatenbank, PASSWORD_DEFAULT)) {
$neu = password_hash($eingabe, PASSWORD_DEFAULT);
// enregistrer $neu dans la base de données
}
// Connexion réussie, renouveler l'ID de session
} else {
usleep(random_int(200000, 400000)); // temps de réponse homogène
// afficher un message d'erreur uniforme
}
password_needs_rehash() fait en sorte que d'anciens hachages soient automatiquement convertis à la méthode actuelle lors de la prochaine connexion. Journalisez les échecs avec l'heure, le compte et l'adresse afin que des schémas apparaissent. Des indications sur l'analyse figurent dans le guide Analyser les journaux du serveur web après une attaque.
Particularités des CMS, boutiques et panneaux
De nombreux systèmes ont, en plus de la page de connexion visible, d'autres voies par lesquelles des identifiants sont vérifiés. Ces entrées secondaires sont souvent oubliées dans la protection.
- WordPress : l'interface
xmlrpc.phpaccepte elle aussi des connexions. Si elle n'est pas nécessaire, par exemple pour d'anciennes applications, bloquez-la dans le serveur web. Vérifiez en outre si des noms d'utilisateur sont visibles via les pages d'auteur ou l'interface REST, et utilisez pour les admins des noms qui n'apparaissent pas publiquement. - Boutiques : en plus de la zone d'administration, les comptes clients sont une cible, surtout pour le credential stuffing. La limitation de débit, les notifications lors de nouvelles connexions et un second facteur facultatif pour les clients aident ici.
- Panneaux d'hébergement et webmail : ces interfaces sont souvent accessibles dans le monde entier et protègent tout le serveur. Elles ne devraient être accessibles que depuis des réseaux connus ou par VPN.
- SSH : la connexion par clé au lieu d'un mot de passe rend inopérante la devinette classique.
Les fonctions de protection fournies par votre système figurent dans la documentation de l'éditeur. Les extensions de tiers devraient être activement maintenues, sinon elles deviennent elles-mêmes un risque. Pour les exploitants WordPress, la page WordPress et PHP2Shell résume les priorités actuelles.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons toutes les pages de connexion accessibles de vos serveurs, du CMS au panneau d'hébergement, et évaluons leur protection.
- Nous mettons en place la limitation de débit, Fail2ban et les restrictions d'accès dans le cadre du renforcement de serveur et les testons.
- Nous accompagnons l'introduction de l'authentification à deux facteurs pour les admins et documentons les accès de secours.
- Avec la surveillance de sécurité, nous gardons en permanence à l'œil les échecs de connexion et les nouveaux comptes administrateur.
Questions fréquentes
À quoi reconnaître une attaque par force brute ?
Sont typiques de nombreuses connexions échouées en peu de temps, souvent contre la même page de connexion et avec des noms d'utilisateur changeants. Dans le journal d'accès, cela se traduit par une accumulation de requêtes POST vers l'adresse de connexion, fréquemment depuis de nombreuses adresses IP différentes.
Faut-il bloquer un compte après plusieurs échecs ?
Prudence : des blocages stricts peuvent être utilisés par des attaquants pour verrouiller des utilisateurs légitimes. Mieux vaut des délais croissants, des blocages limités dans le temps par adresse IP et une notification au titulaire du compte.
Renommer l'adresse de connexion aide-t-il ?
Cela réduit le bruit automatisé dans les journaux, mais n'est pas une vraie protection. Qui connaît ou trouve l'adresse peut continuer d'attaquer. Efficaces sont l'authentification à deux facteurs, la limitation de débit et une restriction de la zone d'administration.
Qu'est-ce que le credential stuffing ?
Les attaquants y essaient des combinaisons d'e-mail et de mot de passe volées auprès d'autres services. Cela fonctionne lorsque des utilisateurs emploient le même mot de passe plusieurs fois. Des mots de passe uniques et un second facteur privent cette méthode de son fondement.