Comment sécuriser les serveurs MySQL/MariaDB

Après des attaques sur les bases de données MongoDB, nous avons également constaté récemment que les serveurs MySQL sont ciblés par des ransomwares. Cela ne devrait pas surprendre, étant donné l'adoption croissante des clouds publics et privés. L'exécution d'une base de données mal configurée dans le cloud peut devenir un handicap majeur.

Dans cet article de blog, nous partagerons avec vous un certain nombre de conseils sur la façon de protéger et de sécuriser vos serveurs MySQL ou MariaDB.

Comprendre le vecteur d'attaque

Citant SCMagazine :
"L'attaque commence par forcer brutalement le mot de passe root pour la base de données MySQL. Une fois connecté, les bases de données et les tables MySQL sont récupérées. L'attaquant crée alors une nouvelle table appelée "WARNING" qui comprend une adresse e-mail de contact, une adresse bitcoin et une demande de paiement. ”

D'après l'article, le vecteur d'attaque commence par deviner le mot de passe root MySQL via la méthode de la force brute. L'attaque par force brute consiste en un attaquant essayant de nombreux mots de passe ou phrases de passe dans l'espoir de deviner éventuellement correctement. Cela signifie que les mots de passe courts peuvent généralement être découverts assez rapidement, mais les mots de passe plus longs peuvent prendre des jours ou des mois.

La force brute est une attaque courante qui arriverait à n'importe quel service. Malheureusement pour MySQL (et de nombreux autres SGBD), il n'existe aucune fonctionnalité prête à l'emploi qui détecte et bloque les attaques par force brute à partir d'adresses spécifiques lors de l'authentification de l'utilisateur. MySQL enregistre cependant les échecs d'authentification dans le journal des erreurs.

Revoir votre politique de mot de passe

La révision de la politique de mot de passe MySQL est toujours la première étape pour protéger votre serveur. Le mot de passe root MySQL doit être suffisamment fort avec une combinaison d'alphabets, de chiffres et de symboles (ce qui le rend plus difficile à retenir) et stocké dans un endroit sûr. Changez régulièrement le mot de passe, au moins tous les trimestres civils. Basé sur le vecteur d'attaque, c'est le point le plus faible ciblé par les pirates. Si vous appréciez vos données, ne négligez pas cette partie.

Les déploiements MySQL effectués par ClusterControl suivront toujours les meilleures pratiques de sécurité du fournisseur, par exemple, aucun hôte générique ne sera défini pendant GRANT et les informations d'identification de connexion sensibles stockées dans le fichier de configuration ne sont autorisées que pour l'utilisateur racine du système d'exploitation. Nous recommandons fortement à nos utilisateurs de spécifier un mot de passe fort lors de la phase de déploiement.

Dans un environnement de production standard, les serveurs de base de données sont généralement situés à un niveau inférieur. Cette couche doit être protégée et uniquement accessible depuis le niveau supérieur, comme l'application ou l'équilibreur de charge. Si la base de données est colocalisée avec l'application, vous pouvez même verrouiller les adresses non locales et utiliser le fichier de socket MySQL à la place (moins de surcharge et plus sécurisé).

La configuration du paramètre "bind-address" est ici vitale. Notez que la liaison MySQL est limitée à aucune, une ou toutes les adresses IP (0.0.0.0) sur le serveur. Si vous n'avez pas le choix et avez besoin que MySQL écoute toutes les interfaces réseau, limitez l'accès au service MySQL à partir de bonnes sources connues. Utilisez une application de pare-feu ou un groupe de sécurité pour mettre en liste blanche l'accès uniquement des hôtes qui doivent accéder directement à la base de données.

Parfois, le serveur MySQL doit être exposé à un réseau public à des fins d'intégration (par exemple, surveillance, audit, sauvegarde, etc.). C'est bien tant que vous dessinez une bordure autour de lui. Ne laissez pas les sources indésirables « voir » le serveur MySQL. Vous pouvez parier combien de personnes dans le monde savent que 3306 est le port par défaut pour le service MySQL, et en effectuant simplement une analyse de port par rapport à une adresse réseau, un attaquant peut créer une liste de serveurs MySQL exposés dans le sous-réseau en moins d'une minute. Il est conseillé d'utiliser un port MySQL personnalisé en configurant le paramètre "port" dans le fichier de configuration MySQL pour minimiser le risque d'exposition.

Revoir la politique de l'utilisateur

Limitez certains utilisateurs à détenir les droits d'administration critiques, en particulier GRANT, SUPER et PROCESS. Vous pouvez également activer super_read_only si le serveur est un esclave, disponible uniquement sur MySQL 5.7.8 et Percona Server 5.6.21 et versions ultérieures (malheureusement pas avec MariaDB). Lorsqu'il est activé, le serveur n'autorisera aucune mise à jour, à part la mise à jour des référentiels de réplication si les journaux d'état des esclaves sont des tables, même pour les utilisateurs disposant du privilège SUPER. Supprimez la base de données de test par défaut et tous les utilisateurs avec des mots de passe vides pour réduire la portée de la pénétration. Il s'agit de l'un des contrôles de sécurité effectués par ClusterControl, implémenté en tant que conseiller de base de données.

C'est aussi une bonne idée de limiter le nombre de connexions autorisées à un seul compte. Vous pouvez le faire en définissant la variable max_user_connections dans mysqld (la valeur par défaut est 0, égale à illimité) ou utilisez les options de contrôle des ressources dans les instructions GRANT/CREATE USER/ALTER USER. L'instruction GRANT prend en charge la limitation du nombre de connexions simultanées au serveur par un compte, par exemple :

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

Le nom d'utilisateur par défaut de l'administrateur sur le serveur MySQL est "root". Les pirates tentent souvent d'accéder à ses autorisations. Pour rendre cette tâche beaucoup plus difficile, renommez "root" en autre chose. Les noms d'utilisateur MySQL peuvent comporter jusqu'à 32 caractères (16 caractères avant MySQL 5.7.8). Il est possible d'utiliser un nom d'utilisateur plus long pour l'utilisateur super administrateur en utilisant l'instruction RENAME comme indiqué ci-dessous :

mysql> RENAME USER root TO new_super_administrator_username;

Remarque pour les utilisateurs de ClusterControl, ClusterControl doit connaître l'utilisateur root et le mot de passe MySQL pour automatiser et gérer le serveur de base de données pour vous. Par défaut, il recherchera "root". Si vous renommez l'utilisateur root en autre chose, spécifiez "monitored_mysql_root_user={new_user}" dans cmon_X.cnf (où X est l'ID du cluster) et redémarrez le service CMON pour appliquer la modification.

Politique de sauvegarde

Même si les pirates ont déclaré que vous récupéreriez vos données une fois la rançon payée, ce n'était généralement pas le cas. L'augmentation de la fréquence de sauvegarde augmenterait la possibilité de restaurer vos données supprimées. Par exemple, au lieu d'une sauvegarde complète une fois par semaine avec une sauvegarde incrémentielle quotidienne, vous pouvez planifier une sauvegarde complète une fois par jour avec une sauvegarde incrémentielle horaire. Vous pouvez le faire facilement avec la fonction de gestion des sauvegardes de ClusterControl et restaurer vos données en cas de problème.

Si vous avez activé les journaux binaires (binlogs), c'est encore mieux. Vous pouvez créer une sauvegarde complète tous les jours et sauvegarder les journaux binaires. Les binlogs sont importants pour la récupération ponctuelle et doivent être sauvegardés régulièrement dans le cadre de votre procédure de sauvegarde. Les administrateurs de base de données ont tendance à manquer cette méthode simple, qui vaut chaque centime. En cas de piratage, vous pouvez toujours récupérer jusqu'au dernier point avant que cela ne se produise, à condition que les pirates n'aient pas purgé les journaux binaires. Notez que la purge des journaux binaires n'est possible que lorsque l'attaquant dispose du privilège SUPER.

Une autre chose importante est que les fichiers de sauvegarde doivent pouvoir être restaurés. Vérifiez les sauvegardes de temps en temps et évitez les mauvaises surprises lorsque vous devez restaurer.

Protégez votre serveur Web/d'applications

Eh bien, si vous avez isolé vos serveurs MySQL, les attaquants ont encore des chances d'y accéder via le Web ou le serveur d'applications. En injectant un script malveillant (par exemple, Cross-Site Scripting, injection SQL) sur le site Web cible, on peut accéder au répertoire de l'application et avoir la possibilité de lire les fichiers de l'application. Ceux-ci peuvent contenir des informations sensibles, par exemple, les identifiants de connexion à la base de données. En regardant cela, un attaquant peut simplement se connecter à la base de données, supprimer toutes les tables et laisser une table de « rançon » à l'intérieur. Il n'est pas nécessaire d'être un utilisateur root de MySQL pour racheter une victime.

Il existe des milliers de façons de compromettre un serveur Web et vous ne pouvez pas vraiment fermer le port entrant 80 ou 443 à cette fin. Une autre couche de protection est nécessaire pour protéger votre serveur Web contre les injections basées sur HTTP. Vous pouvez utiliser Web Application Firewall (WAF) comme Apache ModSecurity, NAXSI (WAF pour nginx), WebKnight (WAF pour IIS) ou simplement exécuter vos serveurs Web dans un réseau de diffusion de contenu (CDN) sécurisé comme CloudFlare, Akamai ou Amazon CloudFront.

Toujours rester à jour

Vous avez probablement entendu parler de l'exploit critique MySQL zero-day, où un utilisateur non privilégié peut se transformer en super utilisateur ? Cela semble effrayant. Heureusement, tous les fournisseurs connus ont mis à jour leur référentiel pour inclure un correctif de bogue pour ce problème.

Pour une utilisation en production, il est fortement recommandé d'installer les packages MySQL/MariaDB à partir du référentiel du fournisseur. Ne comptez pas sur le référentiel du système d'exploitation par défaut, où les packages sont généralement obsolètes. Si vous exécutez dans un environnement de cluster comme Galera Cluster, ou même la réplication MySQL, vous avez toujours le choix de corriger le système avec un temps d'arrêt minimal. Faites-en une routine et essayez d'automatiser autant que possible la procédure de mise à niveau.

ClusterControl prend en charge la mise à niveau progressive de la version mineure (un nœud à la fois) pour MySQL/MariaDB en un seul clic. La mise à niveau des versions majeures (par exemple, de MySQL 5.6 à MySQL 5.7) nécessite généralement la désinstallation des packages existants et c'est une tâche risquée à automatiser. Une planification et des tests minutieux sont nécessaires pour ce type de mise à niveau.

Conclusion

Le ransomware est un pot d'or facile à gagner. Nous verrons probablement plus de failles de sécurité à l'avenir, et il vaut mieux agir avant que quelque chose ne se produise. Les pirates ciblent de nombreux serveurs vulnérables et il est très probable que cette attaque se propagera également à d'autres technologies de base de données. La protection de vos données est un défi constant pour les administrateurs de bases de données. Le véritable ennemi n'est pas le délinquant, mais notre attitude à l'égard de la protection de nos actifs critiques.