Sécuriser WordPress 4 : Blocage des attaques communes de vulnérabilité de WordPress
Vous gaspillez beaucoup de ressources avec des scripts automatisés qui essaient de trouver des vulnérabilités connues dans WordPress. Cet article couvrira comment configurer le serveur http d’Apache pour reconnaître quelques modèles de sondages communs utilisés, dans les thèmes et des plugins. Après avoir identifié un tel sondage, l’IP source peut être bloquée automatiquement à l’aide de règles de pare-feu temporaires.
Attention : essayez de mettre en œuvre les changements de configuration mentionnés ci-dessous, que si vous en compreniez les effets et êtes capables de revenir en arrière si nécessaire. Il est bien sûr recommandé fortement de sauvegarder tout ce qui doit l’être avant toute manipulation.
Même si vous n’utilisez pas WordPress sur votre serveur, vous risquez toujours d’avoir des exploits comme celui-ci et bénéficier de la mise en œuvre des techniques de blocage décrites ci-après.
Ces instructions concernent le serveur web Apache. Sauf indication contraire, tous les exemples de code sont utilisables pour les configurations httpd ou à travers les .htaccess.
Ce sera un processus en deux étapes. La première étape consiste à configurer Apache pour émettre 403 réponses lors de la détection de sondage pour les vulnérabilités communes de WordPress. Cette étape peut être utilisée avec succès indépendamment de l’utilisation de WordPress car les attaques seront les mêmes. La seconde étape consistera à bloquer les 403 réponses répétées en utilisant Fail2Ban tel que décrit dans l’article précédent.
1. Les tentatives de téléchargement de wp-config.php
Le premier fichier que nous voulons protéger est une cible de grande valeur, le fichier « wp-config.php » qui contient des mots de passe de bases de données et d’autres informations sensibles sur la façon dont votre service s’exécute.
Une façon courante d’obtenir le fichier de configuration de WordPress est de manipuler des plug-ins et des thèmes qui offrent une possibilité de télécharger des fichiers, et de le forcer à retourner « wp-config.php » tant que téléchargement. Pour ce faire, ils créent des URL comme « /wp-content/plugins/downloader/download.php?file=../../../wp-config.php ».
Même si vous ne disposez pas de ces plug-ins, il est bien de bloquer ces demandes. Pour traquer cette astuce néfaste, il nous faut trouver un dénominateur commun à ces attaques, c’est simple en fait, c’est dans la chaîne de requête que se trouve la réponse, elles contiennent toutes « wp-config.php ». Cette chaine, qui ne peut jamais être une une demande légitime, va nous permettre de configurer apache par une règle simple et efficace.
Si votre serveur web n’est pas bien configuré, il est même possible que ce fichier soit récupéré sans l’aide de plug-ins ou thèmes
<Location "/wp-content/">
<If "%{QUERY_STRING} =~ /wp-config.php/">
Deny from all
</If>
</Location>
Pour réduire le risque d’accès direct, de nombreux articles vous indiquent de bloquer les requêtes directes pour le fichier spécifique dans Apache. Malheureusement, en raison d’erreurs et de manières humaines, de nombreuses variantes de ce nom de fichier sont susceptibles d’exister temporairement sur votre serveur et tout ce qui est temporaire risque d’être oublié. Ce ne sont que les principales variantes demandées de ce fichier sur les serveurs, mais c’est assez potentiellement parlant :
/wp-config.php~, /wp-config.php.bak, /wp-config.php.old, /wp-config.php2, /wp-config.php1, /wp-config.php.rpmnew, /wp-config.bak, /wp-config.php.save, /wp-config.php.rpmsave, /wp-config.php_old, /wp-config.php.tmp, /wp-config-backup.php, /wp-config.old, /wp-config.txt, etc.
Vous reconnaîtrez au moins certains des éléments ci-dessus, comme sauvegarde humaine temporaire (qui dure), ou sauvegarde automatique de fichier créés par des éditeurs de texte. De toute évidence, le blocage d’une correspondance directe pour « /wp-config.php » n’est pas suffisant et une correspondance plus large que ce qui est habituellement recommandé est nécessaire :
<Location "/wp-config*">
Deny from all
</Location>
2. L’utilisation de formulaire d’enregistrement
Maintenant que le sondage qui cible le fichier de configuration principal de WordPress est sous contrôle, nous allons examiner rapidement le système de connexion WordPress. Il propose déjà 403 réponses, suite à des tentatives de connexions échouées, donc il n’y a pas grand chose à faire là-bas. Cependant, lorsque vous avez désactivé les enregistrements dans WordPress, seuls les robots vont essayer d’enregistrer un nouveau compte. Bloquer les tentatives d’accès au formulaire d’inscription directement est une bonne idée :
<Location "/wp-login*">
<If "%{QUERY_STRING} =~ /action=register/">
Deny from all
</If>
</Location>
Celui-ci seul peut correspondre jusqu’à 6% des activités de bot. L’enregistrement d’un nouveau compte est généralement la troisième chose qu’ils essaient de faire après avoir tenté d’extraire le fichier de configuration de WordPress.
3. Limiter les accès au thème courant
J’ai mentionné plus tôt que les problèmes proviennent en majorité de thèmes et pas seulement des plugins populaires. C’est surtout parce que certains thèmes ont aussi des fonctions avancées de configuration ou de plus en plus regroupent un ensemble de plugins. La caractéristique commune de tous ces sondages est qu’ils demandent tous des fichiers se terminant par « .php » dans le répertoire du thème.
Il peut être considérablement amélioré en bloquant l’invocation directe des fichiers .php dans tout votre répertoire de thèmes. Le blocage des fichiers .php dans le répertoire des thèmes aura pour mérite de bloquer la plupart des attaques contre les vulnérabilités connues dans les thèmes populaires. Attention tout de même, si votre thème n’est pas correctement développé, cela pourrait nuire à son bon fonctionnement.
Pour commencer, votre site n’utilise qu’un thème, donc pourquoi en garder plusieurs ? Donc un peu de ménage serait une bonne idée. Ensuite rajouter cette règle afin de bloquer toute intrusion sur ce point.
Remplacez le nom du thème de l’exemple, ci-dessous twentysixteen, par le nom du thème que vous utilisez :
<LocationMatch "^/wp-content/themes/(.*.php|(?!twentysixteen))">
Deny from all
</LocationMatch>
La mise en œuvre de cette règle est risquée, si vous venez de changer le thème que vous utilisez, pensez à le mettre à jour.
4. Bloquer les accès à wp-admin
Une bonne pratique est de renommer de différentes manières ce dossier. Mais même si vous le faite, la règle suivante réduira le nombre de demande HTTP en amont pour servir une page 404. Comme toutes les méthodes précédentes, cela libérera les ressources du serveur plutôt que de laisser les attaques les grignoter.
<LocationMatch "^/(cgi-bin|admin|(?!wp-admin).*admin">
Deny from all
</LocationMatch>
<LocationMatch ".(?:as[px]{1,2}|cfm|cgi|jsp[x]?|p[ly])$">
Deny from all
</LocationMatch>
Maintenant, toutes les requêtes qui correspondent à l’une des règles ci-dessus obtiendront une erreur HTTP 403 Forbidden.
Cela a trois avantages principaux :
- httpd offrira un 403 beaucoup plus rapide que php + mysql + wordpress peut servir un 404, libérant des ressources pour les utilisateurs réels.
- certaines attaques automatiques abandonnent après seulement quelques tentatives lorsque vous renvoyez 403 au lieu des 404 ou 200 attendus.
- Ils sont beaucoup plus faciles à suivre afin de bloquer l’accès temporairement.
Le retour d’un 403 ne les empêche pas d’essayer d’autres adresses, mais heureusement, les erreurs 403 répétées dans les fichiers de log seront maintenant un élément différenciant les visiteurs des robots de sondage.
Consultez l’article sur WP & Fail2Ban pour repérer et utiliser les réponses 403.
5. Séparer le bon grain de l’ivraie
Enfin, il vous faut inclure les chemins que nous avons bloqués ci-dessus dans les blocs de directives dans votre fichier /robots.txt. Cela empêchera les robots ‘Officiels’ qui utilise ce fichier, comme Bingbot et Googlebot d’être identifiés par inadvertance comme des robots de sondage et d’éviter de temporairement verrouillés votre site à leur visite.
Voici un exemple de liste que vous devriez utiliser dans le fichier robots.txt à la racine de votre site :
User-Agent: * Disallow: /cgi-bin/ Disallow: /wp-admin Disallow: /wp-config* Disallow: /wp-content/themes/*.php Disallow: /wp-login.php Disallow: /*.asp* Disallow: /*.cfm Disallow: /*.cgi Disallow: /*.|jsp* Disallow: /*.pl Disallow: /*.py
Et voilà, si vous avez trouvé cet article intéressant, et que vous avez des éléments que vous voudriez rajouter, à vos commentaires !
Pas de commentaire