Qu’est-ce que le brute force ?

Rien de tel qu’une article Wikipédia pour nous l’expliquer :

L’attaque par force brute est une méthode utilisée en cryptanalyse pour trouver un mot de passe ou une clé. Il s’agit de tester, une à une, toutes les combinaisons possibles.

Attaque par force brute – Wikipédia

C’est assez simpliste comme attaque, il suffit de tester un à un la liste de mot de passe compatible. Bien évidemment, des logiciels sont en place pour que l’opération soit automatisée.

Et aujourd’hui, elle est, la plupart du temps, opéré depuis des serveurs piratés/vérolés (ce qui permet de faire beaucoup de requêtes en parallèle et cibler ainsi plus de sites et/ou tester beaucoup plus de mot de passe par seconde) ou depuis des PC ou autres appareils du quotidiens qui sont piratés ou également vérolés.

La deuxième technique est fortement répandue du fait qu’aujourd’hui, la plupart des pages de connexion ne sont pas accessibles depuis des adresses IPs de datacenter : pour se préserver de ce type d’attaque, certains administrateurs systèmes bloquent systématiquement l’accès aux pages de connexion dès que l’adresse IP est détectée comme provenant d’un datacenter.

Et pour finir le tour de ce type d’attaque, sachez qu’aujourd’hui les hackers ne testent pas toutes les combinaisons, mais « juste » les combinaisons les plus probables : les mots de passes les plus utilisés, les mots de passes possible en exploitant des informations depuis le site lui-même (url du site, nom du compte administrateur, …) ou depuis vos données personnelles visible en ligne (votre date de naissance, retrouvé depuis un réseau social, par exemple).

Ne pas se protéger, la meilleure solution

C’est interloquant comme titre, non ? Oui, ne pas se protéger est la meilleure solution. Ceci consiste tout simplement à fermer la porte pour tout le monde et sans exception. De cette façon, vous ne dépensez pas inutilement de ressources pour identifier si tel ou tel requête fait partie d’une attaque ou non.

Ainsi, restreindre l’accès à wp-login.php et wp-admin à seulement votre adresse IP reste la meilleure solution. Mais ce n’est malheureusement toujours pas possible. C’est notamment le cas quand vous avez des adresses IPs dynamiques, quand vous êtes plusieurs à travailler sur le site, … Bref, faire disparaître la porte peut causer des tas d’inconforts du côté des administrateurs du site.

Pourquoi ne pas utiliser un plugin ?

Là, vite fait, j’ai trois arguments à vous proposer :

• Moins de plugin = moins d’emmerdes sur WordPress. Je ne sais pas si vous avez déjà fait le test mais l’ajout d’un plugin (n’importe lequel) augmente le temps de réponse de WordPress et diminue donc sa vitesse de chargement. Et installer un plugin WordPress c’est aussi un peu plus de risque de bugs et d’instabilité, même si franchement les développeurs de plugins de sécurité WordPress font actuellement un travail très propre. J’estime que le jeu n’en vaut pas la chandelle.
• Faire des actions sur WordPress n’est pas toujours possible. Notamment si on est dans la position d’hébergeur web. Modifier le site d’un client serait très mal vu, même si c’est pour mieux lui protéger, car vous risquez fortement d’induire des problèmes dans le site lui-même (incompatibilité avec votre plugin de sécurité, modifications particulières faites sur WordPress par le développeur, …).
• Un plugin WordPress n’a pas les outils nécessaires pour agir en amont. Le plugin WordPress ne peut rien exécuter tant que WordPress n’est pas démarré. Donc, à chaque requête, WordPress démarre d’abord, avant qu’un plugin de sécurité ne puisse finalement annuler la requête d’un attaquant. Agir à un niveau plus haut permet d’empêcher WordPress de gaspiller un temps de chargement et des ressources pour les attaquants.
• Bonus ou argument numéro 3 bis (à vous de voir), je vois beaucoup de plugin de sécurité de faire l’erreur de stocker les adresses IPs bloqués dans MySQL. Le souci se manifeste quand vous commencez à avoir 40 000 ou 70 000 IPs bloqués. C’est un nombre tout à fait raisonnable vu le fléau d’attaque sur internet, mais c’est très « amateur » de vouloir rechercher des données sur 70 000 lignes sur MySQL à chaque ouverture de page. Et encore pire quand on sait que l’adresse IP est stocké dans un champ non indexé ou un champ VARCHAR ou TEXT. Et loguer tout cela, en prime, c’est l’enfer. Or, avec des outils comme fail2ban, il y a des moyens de loguer cela en asynchrone.

Et de l’autre côté, j’ai quelques 3 avantages à mettre en avant :

• La mise en place peut se faire sans accès au tableau de bord du site. Ceci permet notamment de protéger en une opération tous les sites d’un même serveur.
• Les logs ne sont pas dans MySQL. C’est un avantage non négligeable pour garder la base de données WordPress léger et rapide à accéder. wp_postmeta chauffe déjà assez.
• Le blocage se fait au niveau du service web voire même au niveau du kernel (iptables) ce qui permet d’économiser les ressources.

Mise en place de la protection bruteforce sur NGINX

Dans un premier temps, j’ai ajouté une zone de limite de requête dans NGINX :

echo "limit_req_zone $server_name$binary_remote_addr zone=wpratelimit:10m rate=10r/m;" > /etc/nginx/conf.d/wp-rate-limit.conf

Vous pouvez notamment constater :

• limit_req_zone : la directive NGINX utilisée
• $server_name$binary_remote_addr : la clé d’identification du client. Dans mon cas, j’ai mis à la fois $server_name (nom du site) et $binary_remote_addr (adresse IP du client en binaire) pour pouvoir identifier les clients différemment par site. Ceci me permet de ne pas bloquer un client parce qu’il accède à 10 sites WordPress sur le même serveur.
• zone=wpratelimit:10m : création de la zone « wpratelimit » et qui a 10 Mo de taille
• rate=10r/m : la limite est de 10 requêtes par minute.

Ensuite, il faut appliquer cette zone de limite aux fichiers wp-login.php et xmlrpc.php. Pour ma part, j’ai imbriqué les directives location étant donné que j’utilise fastcgi directement pour servir les fichiers PHP :

location ~ \.php$ {
    [...]

    location ~* (wp-login|xmlrpc)\.php$ {
      limit_req zone=wpratelimit;
      add_header RateLimit "yes";
    }
  }

Si vous utilisez NGINX comme reverse proxy, il faudra implémenter différemment, mais le principe reste le même. Il faudra également avoir un log d’erreur que fail2ban analysera régulièrement :

error_log /home/monsite/logs/error.log

N’oubliez pas de recharger NGINX après les modifications :

systemctl reload nginx

Bloquer les attaques répétés avec fail2ban

Une fois les attaques par bruteforce bloqués sur NGINX, il faudra bloquer les attaques répétés depuis iptables pour réduire le risque de sécurité (un attaquant pourrait potentiellement essayer autre chose que WordPress) et les ressources consommés.

Pour cela, il faut créer un nouveau filtre fail2ban dans /etc/fail2ban/filter.d/wp-rate-limit.conf :

[Definition]
ngx_limit_req_zones = wpratelimit
failregex = ^\s*\[[a-z]+\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "(?:%(ngx_limit_req_zones)s)", client: <HOST>,
ignoreregex =
datepattern = {^LN-BEG}

Notez que c’est basé sur le fichier etc/fail2ban/filter.d/nginx-limit-req.conf disponible sur fail2ban par défaut.

Ensuite, dans /etc/fail2ban/jail.local, j’ajoute un nouveau prison :

[wp-rate-limit]
enabled = true
bantime = 86400
maxretry = 3
logpath = /home/*/logs/error.log tail

Comme vous voyez, je bloque pour 86 400 secondes (24h si vous voulez) au bout de 3 blocages détectés sur NGINX. Et j’analyse les fichiers d’erreurs sur /home/*/logs/error.log. Le tail à la fin de logpath me permet de ne pas recharger les fichiers en entier au démarrage de fail2ban, ce qui diminue fortement la charge I/O engendrée (ça se voit beaucoup sur un serveur à 1000 sites).

N’oubliez pas de redémarrer fail2ban par la suite :

systemctl restart fail2ban

Place aux tests

Pour tester, j’ai utilisé Apache Benchmark (ab) pour effectuer « beaucoup » de requêtes sur wp-login.php :

ab -n 20 https://www.monsite.com/

Au bout de 10 requêtes, l’IP est bloquée. On peut constater cela depuis le fail2ban-client :

fail2ban-client status wp-rate-limit

Et les blocages faites par NGINX sont logués :

[root@serveur ~] tail /home/monsite/logs/error.log
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"
2022/05/06 20:49:03 [error] 14560#14560: *312 limiting requests, excess: 0.991 by zone "wpratelimit", client: 1.2.3.4, server: www.monsite.com, request: "GET /wp-login.php HTTP/1.0", host: "www.monsite.com"

Désactiver l’accès SSH avec mot de passe

Un mot de passe ne signifie quasiment plus rien en 2022. Si auparavant, celui-ci permettait de sécuriser l’accès à un service, aujourd’hui, nous avons atteint un capacité de calcul et un capacité de trafic réseau suffisamment énorme pour envisager d’essayer toutes les caractères possibles.

Cette technique s’appelle le bruteforce et consiste tout simplement à demander à un ou plusieurs PC, Mac, serveurs Linux, votre frigo connecté ou votre smartphone, d’essayer un à un une liste de mot de passe sur un service. Grâce à internet et une petite armée d’appareils infectés, les hackers arrivent à essayer des milliers si ce n’est des millions de combinaisons de mots de passe en quelques minutes. Il est aussi courant de voir des pirates louer des serveurs ou pirater des sites justement pour cet usage.

Le meilleur moyen de leur couper l’herbe sous le pied et tout simplement de ne pas disposer de mot de passe. S’il n’y a pas de mot de passe à pirater, alors leur bruteforce ne vont pas du tout aboutir.

En remplacement du mot de passe, nous pouvons utiliser la cryptographie à notre avantage et utiliser donc une paire de clé privée/publique pour s’authentifier sur notre serveur SSH.

Création d’une paire de clé SSH

Vous pouvez créer une paire de clé SSH depuis votre PC ou depuis le serveur lui-même. D’ailleurs vous pouvez le créer sur n’importe quel appareil. Sous Windows, l’outil PuTTY vous permet de le faire. Sous Linux et Mac, vous pouvez utiliser la commande suivante :

ssh-keygen -t rsa

L’option -t rsa permet d’indiquer l’algorithme à utiliser. Une fois vos clés créés, vous devez être en possession d’une clé privée et d’une clé publique.

Autoriser la clé SSH à se connecter à un utilisateur sur le serveur SSH

Ensuite, il s’agit d’ajouter votre clé SSH à un utilisateur du serveur. Pour cela, ouvrez le fichier de clé publique qui devrait contenir la clé publique de la forme ssh-rsa XXXXXXXXXXXX(…) user@hostname. Copiez tout cela et ajoutez-le au fichier /root/.ssh/authorized_keys du serveur (créez le fichier et le dossier si nécessaire).

Une fois ajouté au fichier, essayez de vous connecter au SSH. Le serveur ne devrait plus vous demander de mot de passe lors de la connexion.

Désactiver la connexion par mot de passe

Enfin, nous pouvons désactiver la connexion par mot de passe pour l’utilisateur root. Dans le fichier de configuration de votre serveur SSH (/etc/ssh/sshd_config), remplacez :

PermitRootLogin yes

par :

PermitRootLogin without-password

et redémarrez le service SSH :

systemctl restart sshd

Bannir les tentatives de connexion avec mauvais mot de passe avec fail2ban

Une autre chose qui peut être faite est de bannir une adresse IP s’il a obtenu trop d’échec de connexion pour mauvais mot de passe. L’outil fail2ban est justement destiné à cet usage. Pour l’installer :

apt-get install -y fail2ban

Ensuite, pour la configuration, il nous faudra créer le fichier /etc/fail2ban/jail.local avec comme contenu :

[DEFAULT]
bantime = 3600

[sshd]
maxretry = 3
action = iptables-multiport

Dans la section DEFAULT, je définis le temps de blocage sur 3600 secondes (1 heure). Ceci s’appliquera alors à tous les services surveillé par fail2ban. Rien ne vous empêche de spécifier un bantime différent par service en utilisant la même directive dans les sections des services.

La section sshd s’applique du coup pour le service SSH uniquement. J’ai mis maxretry sur 3 pour limiter la connexion à 3 tentatives. L’action iptables-multiport est une action prédéfinie dans fail2ban qui permet de bloquer l’adresse IP détectée sur tous les ports du serveurs et ce en utilisant IPTables.

Maintenant, il s’agit de démarrer fail2ban :

systemctl restart fail2ban

N’oublions pas de l’activer au démarrage :

systemctl enable fail2ban

Vous pouvez ensuite visualiser l’état global de fail2ban avec la commande suivante :

fail2ban-client status

Et vous pouvez voir l’état du monitoring du SSH avec la commande suivante :

fail2ban-client status sshd

Je ne serais pas du tout surpris que vous aillez déjà quelques adresses IP bloqués. Vive internet.

Limiter l’accès SSH à quelques adresses IP de confiance

C’est la solution que je préconise au maximum. Si un voleur ne peut pas toucher votre porte, alors il ne pourra pas faire sauter votre serrure. Malheureusement, je suis dans un cas où mon adresse IP n’est pas fixe, et par conséquent, je peux risquer de me bloquer moi-même si je mets une adresse IP aujourd’hui et que demain je ne peux plus m’y connecter en utilisant cette même adresse IP.

Ainsi, j’utilise l’approche suivante. J’ai listé tous les adresses IPs que mes fournisseurs d’accès Internet pourraient me fournir. Ceci se liste facilement grâce aux informations liés au ASN et aux routes BGP ainsi associés. Pour faire simple, un fournisseur d’accès Internet dispose généralement sa propre numéro AS (le ASN du coup) et chaque adresse IP est associé à un ASN. Une fois l’ASN de votre fournisseur identifié sur peeringdb.com, vous pouvez rechercher les blocs d’IPs associés sur hackertarget.

J’ajoute dans la liste également quelques adresses IPs de confiance, notamment l’adresse IP de quelques un de mes autres serveurs, au cas où je suis vraiment bloqué et que je dois utiliser un autre de mes serveurs pour se frayer un chemin dans ce serveur en particulier. C’est toujours mieux que se connecter sur une console KVM over IP.

C’est une sacré liste, mais pas aussi grande qu’Internet tout entier. Ca coupe déjà l’herbe sous le pied de pas mal de machines infectés et de hackers malintentionnés. C’est mieux que rien.

Maintenant qu’on a la liste à autoriser, configurons le pare-feu. Pour ma part, j’utilise IPSet avec IPTables qui me permet de lister un grand nombre de plage IP sans perdre trop de performances. Commençons par créer le set d’IP autorisé à se connecter en SSH :

ipset -N admin hash:net

Ensuite, ajoutons-y des adresses IP :

ipset -A admin 1.2.3.4

Evidement, 1.2.3.4 a vocation à être remplacé par une adresse IP ou un CIDR. Enfin, autorisons ce set d’IP sur le port 22 :

iptables -A INPUT -p tcp --dport 22 -m set --match-set admin src -j ACCEPT

Et enregistrons les modifications :

ipset save > /etc/ipset.conf
iptables-save > /etc/iptables/rules.v4

Si vous n’avez pas iptables-save, alors il faut installer iptables-persistent :

apt-get install iptables-persistent

Et voilà, votre service SSH est désormais limité aux adresses IPs que vous avez fournis.