Renforcer MySQL pour votre site WordPress

WordPress, le CMS le plus populaire, fonctionne sur MySQL, la base de données la plus populaire du marché. Passer du temps à vous assurer que votre installation MySQL et l'installation de la configuration de la base de données WordPress sont suffisamment renforcées contre les vecteurs d'attaque courants peut vous aider à réduire les risques. Cela est particulièrement vrai si vous gérez vous-même votre serveur MySQL.

Il convient de noter que de nombreuses installations WordPress utilisent MariaDB, qui est un fork de MySQL. Comme les deux fonctionnent de manière très similaire, nous utiliserons MySQL pour désigner à la fois MySQL et MariaDB. Quelle que soit la variante RDMS que vous utilisez, le renforcement de votre MySQL peut vous aider à minimiser les risques d'attaques de pirates. Cependant, cela ne remplace pas d'autres mesures de sécurité, telles que l'installation d'un pare-feu d'application Web, la garantie que vous disposez de la dernière version des plugins, des thèmes et de WordPress, et le renforcement de WordPress.

Dans cet article, qui s'adresse principalement à ceux qui gèrent leur propre MYSQL, nous proposons plusieurs conseils et tutoriels sur la façon de sécuriser MySQL. Même ainsi, la liste complète des meilleures pratiques présentées dans cet article vaut la peine d'être lue pour quiconque gère des sites Web WordPress. La sécurisation de votre serveur MySQL est une étape critique pour maintenir un WordPress sécurisé et vous protéger contre différents types d'attaques par force brute, d'injection de logiciels malveillants et d'autres types d'attaques.

Table des matières

• Envisagez d'utiliser une base de données en tant que service (DBaaS
• Gardez MySQL à jour
• Exécutez MySQL sur une machine dédiée
• Lier MySQL à une adresse IP
• Limitez l'utilisation des outils d'interface graphique basés sur le Web
• Exécutez le démon MySQL à l'aide d'un utilisateur dédié
• Utilisez le script mysql_secure_installation
• Créer un utilisateur de base de données WordPress dédié
• Assurez-vous que local_infile est désactivé
• Désactiver l'historique des commandes MySQL
• Assurez-vous que mysqld n'est pas démarré avec l'argument –skip-grant-tables
• Sauvegardez votre base de données
• • Effectuez des sauvegardes fréquentes
  • Vérifiez fréquemment l'intégrité de vos sauvegardes
  • Stockez vos sauvegardes en toute sécurité
• Activer et appliquer les connexions TLS
• • Changer le préfixe du tableau
  • Comment mettre en œuvre les changements
  • Sécuriser votre WordPress

Envisagez d'utiliser une base de données en tant que service (DBaaS)

La base de données en tant que service vaut la peine d'être envisagée si vous n'hébergez pas WordPress sur un plan géré. Il remplace le modèle traditionnel d'installation locale de MySQL par un service auquel vous vous connectez. Cela peut convenir à votre cas d'utilisation si vous exécutez votre site WordPress avec un fournisseur d'hébergement qui propose des services de base de données gérés. Les options disponibles incluent généralement Amazon RDS, DigitalOcean Managed MySQL et Linode Managed MySQL). À première vue, ces services peuvent être plus coûteux que d'exécuter vous-même MySQL. Cependant, ils font tout le gros du travail pour exécuter des bases de données de niveau production. La plupart des services incluent des préréglages de meilleures pratiques de sécurité, des correctifs de sécurité et une maintenance en cours, ainsi que des sauvegardes.

L'utilisation d'une base de données en tant que service (DBaaS) est l'une des meilleures options en termes de sécurité et de fiabilité. Bien que ce ne soit pas obligatoire, c'est toujours un bon à avoir. Cependant, si vous cherchez à gérer MySQL vous-même, voici une série de conseils de renforcement à garder à l'esprit.

Gardez MySQL à jour

Tout comme il est important de s'assurer que vous utilisez la dernière version de WordPress, il est important de maintenir MySQL à jour. Comme la plupart des autres logiciels, des mises à jour du serveur MySQL sont publiées périodiquement. Ces mises à jour corrigent les bogues, atténuent les vulnérabilités et fournissent de nouvelles fonctionnalités. Vous devez maintenir MySQL à jour avec les derniers correctifs de sécurité afin de réduire les risques liés à l'exécution de logiciels présentant des vulnérabilités connues. Gardez à l'esprit qu'une fois mis à jour, vous devrez redémarrer le "démon mysql". Il s'agit d'un processus qui peut entraîner des temps d'arrêt. Comme toujours, planifiez à l'avance.

Exécutez MySQL sur une machine dédiée

De nombreuses installations WordPress exécutent MySQL, PHP et un serveur Web (tel que Nginx ou Apache HTTP Server) sur la même machine. Ce n'est pas optimal, tant en termes de performances que de sécurité. MySQL devrait idéalement fonctionner sur un serveur dédié pour réduire le rayon d'explosion d'une attaque. Si un attaquant parvient à compromettre et à élever les privilèges sur le serveur Web, il sera beaucoup plus difficile pour cet attaquant de se déplacer latéralement et de compromettre également le serveur MySQL.

Lier MySQL à une adresse IP

Vous pouvez configurer MySQL pour n'accepter que les connexions TCP/IP d'une interface IPv4 ou IPv6 spécifique. Tout ce que vous avez à faire est de définir l'option de configuration bind-address sur une adresse IP spécifique. Cela fournit des contrôles et des restrictions supplémentaires sur la façon dont les applications clientes (dans notre cas, WordPress) peuvent se connecter à MySQL. Par défaut, ce paramètre est défini sur *, ce qui signifie que MySQL prêt à l'emploi écoutera sur toutes les interfaces.

Si elles ne sont pas configurées pour écouter une adresse IP spécifique, toutes les adresses IP peuvent être utilisées pour se connecter à MySQL. Ce paramètre est particulièrement important à définir si vous exécutez MySQL sur la même machine qu'un serveur Web que vous exposez à Internet (dans ce cas, vous devez définir l'adresse de liaison sur 127.0.0.1 afin que MySQL n'écoute que sur localhost) .

Par exemple, si vous souhaitez que le serveur MySQL n'accepte que les connexions sur une adresse IPv4 spécifique, vous pouvez ajouter une entrée similaire à l'exemple ci-dessous. Vous devez le saisir sous le groupe d'options [mysqld] dans le fichier de configuration /etc/mysql/mysql.conf.d/mysqld.cnf de votre serveur.

adresse-liaison=192.168.0.24

Notez qu'une fois que vous avez défini cela, vous devrez reconfigurer WordPress pour vous connecter à la base de données en utilisant cette adresse IP (à moins qu'il ne le fasse déjà) car les connexions sur d'autres adresses d'hôte de serveur ne seraient pas autorisées.

Limitez l'utilisation des outils d'interface graphique basés sur le Web

De nombreuses installations WordPress incluent des outils de gestion graphique frontaux basés sur le Web. Les exemples courants incluent Cpanel, phpMyAdmin ou Adminer. Ces outils facilitent la gestion de MySQL et d'autres aspects de l'infrastructure sous-jacente. Alors qu'une interface graphique basée sur le Web peut vous aider à gérer vos bases de données MySQL, ces interfaces peuvent augmenter la surface d'attaque en ajoutant un autre vecteur. De plus, il existe un risque qu'ils soient découverts et exploités par des attaquants pour exécuter des requêtes SQL destructrices ou malveillantes sur votre base de données. Les attaques peuvent même entraîner une prise de contrôle complète de votre site Web WordPress.

Le seul serveur sûr est celui qui est éteint et débranché – cependant, le risque peut être géré. La désinstallation des systèmes non critiques est une option ; cependant, ceux-ci peuvent également être verrouillés et restreints pour minimiser le risque.

Il est possible de restreindre l'accès à ces outils de différentes manières. Vous pouvez installer phpMyAdmin pour WordPress à distance, minimisant ainsi les risques pour le serveur Web. Alternativement, vous pouvez également envisager d'utiliser des outils tels que MySQL Workbench ou Beekeeper Studio sur votre ordinateur local et vous connecter à votre serveur de base de données via un tunnel SSH.

Exécutez le démon MySQL à l'aide d'un utilisateur dédié

Comme pour les autres services exécutés sur un serveur, vous pouvez exécuter le démon MySQL sous un utilisateur dédié. Lorsque vous exécutez MySQL à l'aide d'un utilisateur dédié, vous pouvez définir précisément les autorisations accordées à cet utilisateur dans le système. L'exécution de MySQL sous un utilisateur dédié suit également le principe du moindre privilège, car cela réduit le rayon d'action d'une vulnérabilité MySQL. Cela réduit également la possibilité qu'une mauvaise configuration soit exploitée puisqu'un utilisateur restreint ne pourra pas accéder à des ressources non liées à MySQL (telles que les configurations et les secrets du système d'exploitation).

La bonne nouvelle est que les installations via des gestionnaires de packages (tels que apt ou yum) prennent automatiquement en charge cette étape lors de l'installation de MySQL. Un moyen rapide de vérifier si MySQL s'exécute sous un utilisateur dédié consiste à exécuter ce qui suit sur la machine exécutant le démon MySQL.

ps-ef | egrep « ^mysql.*$ »

Si MySQL s'exécute avec un utilisateur dédié, vous devez vous attendre à voir au moins une ligne de la sortie de ps renvoyée.

Utilisez le script mysql_secure_installation

Le paquet mysql-server est fourni avec un utilitaire de script shell appelé mysql_secure_installation. Vous pouvez utiliser ce script pour configurer un point de départ sécurisé pour le serveur MySQL. En tant que tel, vous devez l'exécuter après une nouvelle installation de MySQL. Cet utilitaire vous aide à :

• Définir un mot de passe pour les comptes root
• Supprimer les comptes root accessibles depuis l'extérieur de localhost
• Supprimer les comptes d'utilisateurs anonymes
• Supprimer la base de données de test (qui, par défaut, est accessible aux utilisateurs anonymes)

Pour invoquer mysql_secure_installation, exécutez la commande suivante :

sudo mysql_secure_installation

Une fois le processus d'installation commencé, plusieurs invites vous demanderont si vous souhaitez activer le plugin de validation de mot de passe, qui est utilisé pour tester la force des mots de passe que vous choisissez pour les utilisateurs de MySQL. Il est recommandé d'activer ce plugin.

Après avoir activé le plugin de validation de mot de passe, le script vous demandera de spécifier une politique de validation de mot de passe. Ici, vous devez choisir une politique de mot de passe fort. Il vous sera ensuite demandé de réinitialiser le mot de passe de l'utilisateur root.

Ensuite, le script vous demandera de supprimer les utilisateurs MySQL anonymes. Ceci est important pour réduire tout risque que des attaquants accèdent au serveur de base de données en tirant parti d'un utilisateur MySQL anonyme.

L'invite suivante vous demandera si vous souhaitez désactiver les connexions à l'aide de l'utilisateur root lors de l'authentification à distance sur le serveur MySQL. L'authentification à distance à l'aide de l'utilisateur root est dangereuse et rarement requise. Au lieu de cela, vous devez soit SSH sur MySQL et utiliser le client MySQL sur le serveur pour vous authentifier en tant qu'utilisateur root ou, de préférence, utiliser un tunnel SSH pour transférer le port MySQL distant vers votre machine locale et vous connecter à l'aide d'un client local.

Ensuite, il vous sera demandé de supprimer les bases de données par défaut (si elles existent) fournies avec MySQL. Il s'agit de la pratique recommandée pour les serveurs MySQL de production.

Enfin, il vous sera demandé si vous souhaitez recharger les tables de privilèges pour que toutes les modifications qui ont été appliquées prennent effet.

Créer un utilisateur de base de données WordPress dédié

Les meilleures pratiques de sécurité dictent la séparation des utilisateurs et des privilèges par fonctions ou rôles. Cela signifie que chaque application qui utilise la base de données doit avoir son propre utilisateur dédié avec le nombre minimum d'autorisations de base de données MySQL requises pour effectuer son travail. En tant que tel, vous vous assurerez que les privilèges des utilisateurs ne vont pas au-delà de ce qui est requis.

Cette pratique devrait s'étendre aux déploiements exécutant plusieurs sites Web WordPress - chaque site Web WordPress devrait avoir sa propre base de données dédiée et son propre utilisateur MySQL. Cela garantit qu'à tout moment, un seul utilisateur a accès à une base de données à la fois et que les utilisateurs ne peuvent pas accéder à d'autres bases de données, évitant ainsi les accès non autorisés et les violations de données.

L'instruction SQL suivante (remplacez <host> et <password> et <database> pour répondre à vos besoins) peut être utilisée pour créer un utilisateur dédié pour votre site Web WordPress et accorder des privilèges pour une utilisation régulière. Gardez à l'esprit que certains plugins WordPress, thèmes et mises à jour WordPress peuvent parfois nécessiter des privilèges supplémentaires pour fonctionner correctement (voir les conseils officiels de WordPress à ce sujet pour plus d'informations).

Assurez-vous que local_infile est désactivé

L'instruction LOAD DATA vous permet de charger des fichiers de données dans des tables de base de données. Dans des conditions spécifiques, cela peut être abusé pour lire des fichiers à partir du serveur MySQL. En tant que tel, à moins que vous n'ayez un cas d'utilisation spécifique pour cela dans votre site WordPress, vous devez désactiver cette fonctionnalité.

Si MySQL et le serveur Web s'exécutent sur la même machine, cela peut permettre à un attaquant d'utiliser l'instruction LOAD DATA LOCAL pour lire des fichiers arbitraires auxquels le processus du serveur Web a accès en lecture. Cela suppose qu'un attaquant a la capacité d'exécuter des instructions SQL arbitraires sur MySQL. Cela peut être le cas avec une vulnérabilité d'injection SQL ou via l'installation d'un plugin WordPress malveillant. C'est une autre raison de séparer votre serveur Web et vos serveurs de base de données.

Par défaut, local_infile est désactivé dans MySQL 8.0 (il était activé par défaut dans les versions antérieures de MySQL). Pour empêcher le serveur MySQL d'accepter les instructions LOAD DATA LOCAL, assurez-vous que le démon mysqld est démarré avec local_infile désactivé.

Désactiver l'historique des commandes MySQL

Sous Linux, les instructions des journaux du client MySQL exécutées de manière interactive sont enregistrées dans un fichier d'historique (généralement situé dans $HOME/.mysql_history). L'historique des commandes MySQL devrait idéalement être désactivé car cela réduit la probabilité d'exposer des informations sensibles, telles que des mots de passe, des clés de chiffrement ou d'autres secrets.

Pour vérifier que les fichiers .mysql_history n'existent pas sur le système, exécutez les commandes suivantes :

trouver /home -nom ".mysql_history"
trouver /root -name ".mysql_history"

Si les commandes ci-dessus renvoient une sortie, supprimez tous les fichiers .mysql_history. De plus, vous pouvez définir $HOME/.mysql_history comme lien symbolique vers /dev/null comme suit :

ln -s /dev/null $HOME/.mysql_history

Assurez-vous que mysqld n'est pas démarré avec l'argument –skip-grant-tables

Si le mot de passe root de MySQL est égaré, bien que ce ne soit pas la méthode préférée, certains administrateurs MySQL peuvent avoir recours à la configuration de MySQL pour qu'il démarre avec l'argument –skip-grant-tables. Lors du démarrage de MySQL avec ce paramètre, il évitera de vérifier ses tables de droits lorsqu'un client se connecte ou exécute une requête, permettant ainsi à n'importe qui, n'importe où (à condition qu'il puisse accéder à la base de données via le réseau), de faire n'importe quoi sur le serveur de base de données.

Pour vous assurer que –skip-grant-tables n'est pas activé, ouvrez le fichier de configuration /etc/mysql/mysql.conf.d/mysqld.cnf de votre serveur et recherchez skip-grant-tables. La valeur doit soit ne pas être définie, soit être définie sur skip-grant-tables = FALSE.

Sauvegardez votre base de données

La sauvegarde de votre base de données WordPress est absolument cruciale pour pouvoir se remettre rapidement d'un sinistre ou d'une attaque. Bien qu'il existe une myriade de façons de sauvegarder votre base de données WordPress - des plugins et services de sauvegarde WordPress aux scripts maison qui effectuent périodiquement un vidage de base de données - voici quelques conseils saillants à garder à l'esprit.

Effectuez des sauvegardes fréquentes

Effectuer des sauvegardes régulières est assez évident et explicite - plus vous effectuez fréquemment des sauvegardes de base de données, plus il sera facile de récupérer d'un incident de perte de données. Bien que la fréquence des sauvegardes dépende du type de site WordPress que vous utilisez, en règle générale, une sauvegarde quotidienne sert bien la plupart des cas d'utilisation.

Vérifiez fréquemment l'intégrité de vos sauvegardes

Vos sauvegardes ne sont utiles que si elles fonctionnent. et vous préféreriez probablement ne pas le savoir pendant que vous êtes au milieu d'un incident essayant de récupérer des données. La solution simple consiste à vérifier fréquemment que vos sauvegardes fonctionnent réellement en effectuant des restaurations de test de temps en temps. Une bonne façon de le faire est de définir un événement de calendrier tous les quelques mois pour passer par une procédure de restauration afin de vous assurer que vos sauvegardes fonctionnent toujours comme prévu. De plus, documenter les étapes de restauration de la base de données est également une bonne idée - moins il y a de conjectures lors de la réponse à un incident, mieux c'est.

Stockez vos sauvegardes en toute sécurité

Ne conservez jamais de sauvegardes de votre site WordPress sur votre serveur Web ou de base de données (en particulier sur votre serveur Web). Les sauvegardes sont un endroit idéal pour les attaquants pour plonger dans les poubelles. Il est fortement conseillé de stocker vos sauvegardes dans un emplacement hors site sécurisé. Si vous effectuez des vidages de base de données périodiques, envisagez de stocker vos vidages de base de données sur un service de stockage d'objets. Ceux-ci peuvent inclure Amazon S3, Cloudflare R2, DigitalOcean Spaces, Linode Object Storage, etc. Suivre cette voie peut être un excellent moyen rentable de stocker vos sauvegardes de base de données. Cependant, faites très attention à ne pas rendre le compartiment de stockage que vous utilisez accessible au public.

Activer et appliquer les connexions TLS

À moins que vous n'exécutiez MySQL sur la même machine que votre serveur Web (ce qui, comme nous l'avons déjà couvert ci-dessus, n'est pas une pratique de sécurité idéale), il est fortement recommandé de chiffrer les données entre WordPress et MySQL à l'aide de Transport Layer Security (certificat TLS), anciennement appelé Secure Socket Layer (certificat SSL).

Par défaut, lorsque vous installez MySQL, il génère automatiquement un certificat auto-signé pour vous. Vous pouvez le vérifier en exécutant ce qui suit (vous pouvez également utiliser le script mysql_ssl_rsa_setup pour générer de nouveaux certificats).

Vous devrez copier ca.pem de la liste ci-dessus (par exemple, via SCP) sur le serveur exécutant votre site Web WordPress. Une fois que vous avez téléchargé le fichier ca.pem sur votre serveur WordPress, vous devrez déplacer le certificat vers le magasin de certificats de confiance du système d'exploitation et mettre à jour le magasin de certificats de confiance comme suit.

sudo mv ca.pem /usr/local/share/ca-certificates/mysql-ca.crt
sudo mise à jour-ca-certificats

Ensuite, vous devez configurer WordPress pour utiliser TLS lors de la connexion à MySQL en ajoutant ce qui suit à votre fichier wp-config.php de votre installation WordPress.

définir('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Une fois que vous avez mis à jour wp-config.php, WordPress initiera des connexions à votre serveur MySQL en utilisant TLS.

Ensuite, il est recommandé d'appliquer les connexions TLS à votre serveur MySQL à l'aide de la variable système require_secure_transport en ajoutant ce qui suit à votre fichier /etc/mysql/mysql.conf.d/mysqld.cnf.

require_secure_transport = ACTIVÉ

Enfin, redémarrez MySQL pour que les modifications prennent effet.

systemctl redémarre mysql

Changer le préfixe du tableau

Par défaut, toutes les tables WordPress sont créées avec le préfixe 'wp_'. Cela peut permettre aux attaquants de réussir plus facilement certaines attaques, telles que l'injection SQL, car ils connaîtraient les noms des tables de la base de données. Bien que cela ne suffise pas à vous protéger, il s'agit d'un exercice simple, recommandé par beaucoup comme la meilleure pratique de sécurité WordPress.

Vous pouvez modifier le préfixe de la base de données pendant le processus d'installation ou à tout moment par la suite, bien que ce dernier soit légèrement plus complexe. Dans tous les cas, vous pouvez trouver des didacticiels en ligne sur la modification du préfixe de la base de données WordPress.

Comment mettre en œuvre les changements

J'espère que cet article vous a fourni un aperçu du renforcement de la sécurité MySQL dans le contexte de l'exécution d'un site Web WordPress. Bien qu'il n'y ait pas de solution miracle dans la sécurité des sites Web, avec quelques efforts, adopter une approche de sécurité en couches et en profondeur rendra l'attaque de votre site Web beaucoup plus difficile pour les attaquants.
Bien que ce guide présente un certain nombre de techniques de renforcement pour MySQL, MySQL n'est qu'un composant de l'écosystème WordPress. En tant que tel, vous devriez également considérer d'autres aspects de la sécurité WordPress couverts dans notre guide de renforcement de la sécurité WordPress. Ceci, associé à des mesures de sécurité éprouvées telles que l'authentification à deux facteurs WordPress, vous aidera à vous assurer que vous êtes aussi en sécurité que possible.

Si cela vous semble lourd à assimiler, rappelez-vous que vous pouvez (et devriez probablement) appliquer progressivement les différentes techniques de durcissement abordées dans ce guide.

Sécuriser votre WordPress

Gardez à l'esprit que les attaquants recherchent souvent des cibles faciles, car ils n'ont pas besoin de déployer autant d'efforts pour exploiter des sites Web faiblement sécurisés. Avoir une longueur d'avance sur la posture de sécurité du prochain site Web WordPress fait de vous une cible moins attrayante.