MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Comment protéger votre base de données MySQL et MariaDB contre les cyberattaques sur un réseau public

Il est parfois inévitable d'exécuter des serveurs de base de données MySQL sur un réseau public ou exposé. Il s'agit d'une configuration courante dans un environnement d'hébergement partagé, où un serveur est configuré avec plusieurs services et s'exécute souvent sur le même serveur que le serveur de base de données. Pour ceux qui ont ce type de configuration, vous devriez toujours avoir une sorte de protection contre les cyberattaques comme le déni de service, le piratage, le cracking, les violations de données; tout ce qui peut entraîner une perte de données. Ce sont des choses que nous voulons toujours éviter pour notre serveur de base de données.

Voici quelques conseils que nous pouvons appliquer pour améliorer notre sécurité MySQL ou MariaDB.

Analysez régulièrement vos serveurs de base de données

La protection contre tout fichier malveillant sur le serveur est très critique. Analysez régulièrement le serveur pour rechercher des virus, des logiciels espions, des logiciels malveillants ou des rootkits, en particulier si le serveur de base de données est colocalisé avec d'autres services tels que le serveur de messagerie, HTTP, FTP, DNS, WebDAV, telnet, etc. Généralement, la plupart des problèmes de piratage de bases de données provenaient de la couche d'application qui fait face au réseau public. Ainsi, il est important d'analyser tous les fichiers, en particulier les fichiers Web/d'application, car ils constituent l'un des points d'entrée pour accéder au serveur. Si ceux-ci sont compromis, le pirate 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.

ClamAV est l'une des solutions antivirus les plus connues et les plus fiables pour une variété de systèmes d'exploitation, y compris Linux. Il est gratuit et très facile à installer et est livré avec un assez bon mécanisme de détection pour rechercher des éléments indésirables sur votre serveur. Planifiez des analyses périodiques dans la tâche cron, par exemple :

0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.log

Ce qui précède mettra à jour la base de données virale ClamAV, analysera tous les répertoires et fichiers et vous enverra un e-mail sur l'état de l'exécution et un rapport tous les jours à 3 heures du matin.

Utiliser des rôles et privilèges utilisateur plus stricts

Lors de la création d'un utilisateur MySQL, n'autorisez pas tous les hôtes à accéder au serveur MySQL avec un hôte générique (%). Vous devez analyser votre hôte MySQL et rechercher toute valeur d'hôte générique, comme indiqué dans la déclaration suivante :

mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user    | host |
+---------+------+
| myadmin | %    |
| sbtest  | %    |
| user1   | %    |
+---------+------+

À partir de la sortie ci-dessus, restreignez ou supprimez tous les utilisateurs qui n'ont que la valeur '%' dans la colonne Hôte. Les utilisateurs qui ont besoin d'accéder au serveur MySQL à distance peuvent être contraints d'utiliser la méthode de tunnellisation SSH, qui ne nécessite pas de configuration d'hôte distant pour les utilisateurs MySQL. La plupart des clients d'administration MySQL tels que MySQL Workbench et HeidiSQL peuvent être configurés pour se connecter à un serveur MySQL via un réglage SSH, il est donc possible d'éliminer complètement la connexion à distance pour les utilisateurs MySQL.

Limitez également le privilège SUPER aux seuls utilisateurs de localhost ou se connectant via un fichier de socket UNIX. Soyez plus prudent lorsque vous attribuez le privilège FILE à des utilisateurs non root, car il autorise la lecture et l'écriture de fichiers sur le serveur à l'aide des instructions LOAD DATA INFILE et SELECT ... INTO OUTFILE. Tout utilisateur à qui ce privilège est accordé peut également lire ou écrire n'importe quel fichier que le serveur MySQL peut lire ou écrire.

Modifier les paramètres par défaut de la base de données

En s'éloignant de la configuration, du nommage et des configurations par défaut, nous pouvons réduire le vecteur d'attaque à un certain nombre de fois. Les actions suivantes sont quelques exemples de configurations par défaut que les administrateurs de bases de données pourraient facilement modifier, mais qui sont souvent ignorés en ce qui concerne MySQL :

  • Modifier le port MySQL par défaut à autre que 3306.
  • Renommer le nom d'utilisateur root MySQL en autre que "root".
  • Appliquez l'expiration du mot de passe et réduisez la durée de vie du mot de passe pour tous les utilisateurs.
  • Si MySQL est colocalisé avec les serveurs d'applications, appliquez la connexion via le fichier de socket UNIX uniquement et arrêtez d'écouter sur le port 3306 pour toutes les adresses IP.
  • Appliquez le chiffrement client-serveur et le chiffrement de la réplication serveur-serveur.

Nous avons en fait couvert cela en détail dans cet article de blog, Comment sécuriser les serveurs MySQL/MariaDB.

Configurer un esclave retardé

Un esclave retardé est juste un esclave typique, cependant le serveur esclave exécute intentionnellement les transactions plus tard que le maître d'au moins un laps de temps spécifié, disponible à partir de MySQL 5.6. Fondamentalement, un événement reçu du maître n'est pas exécuté avant au moins N secondes après son exécution sur le maître. Le résultat est que l'esclave reflétera l'état du maître il y a quelque temps dans le passé.

Un esclave retardé peut être utilisé pour récupérer des données, ce qui serait utile lorsque le problème est détecté immédiatement, dans le délai imparti. Supposons que nous configurions un esclave avec un délai de 6 heures par rapport au maître. Si notre base de données a été modifiée ou supprimée (accidentellement par un développeur ou délibérément par un pirate informatique) dans cet intervalle de temps, il est possible pour nous de revenir au moment juste avant que cela ne se produise en arrêtant le maître actuel, puis en activant le serveur esclave. jusqu'à un certain point avec la commande suivante :

# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;

Où "xxxxx" est le fichier journal binaire et "yyyyy" est la position juste avant que le sinistre ne se produise (utilisez l'outil mysqlbinlog pour examiner ces événements). Enfin, promouvez l'esclave pour qu'il devienne le nouveau maître et votre service MySQL est à nouveau opérationnel comme d'habitude. Cette méthode est probablement le moyen le plus rapide de récupérer votre base de données MySQL dans un environnement de production sans avoir à recharger une sauvegarde. Avoir un certain nombre d'esclaves retardés avec des durées différentes, comme indiqué dans ce blog, plusieurs esclaves de réplication retardée pour la reprise après sinistre avec un faible RTO sur la façon de configurer des serveurs de réplication retardée rentables au-dessus des conteneurs Docker.

Activer la journalisation binaire

Il est généralement recommandé d'activer la journalisation binaire même si vous utilisez un serveur MySQL/MariaDB autonome. Le journal binaire contient des informations sur les instructions SQL qui modifient le contenu de la base de données. Les informations sont stockées sous forme d'"événements" qui décrivent les modifications. Malgré l'impact sur les performances, le fait d'avoir un journal binaire vous permet d'avoir la possibilité de relire votre serveur de base de données au point exact où vous souhaitez qu'il soit restauré, également connu sous le nom de récupération ponctuelle (PITR). La journalisation binaire est également obligatoire pour la réplication.

Lorsque la journalisation binaire est activée, il faut inclure le fichier journal binaire et les informations de position lors d'une sauvegarde complète. Pour mysqldump, l'utilisation de l'indicateur --master-data avec la valeur 1 ou 2 imprimera les informations nécessaires que nous pouvons utiliser comme point de départ pour faire avancer la base de données lors de la relecture ultérieure des journaux binaires.

Lorsque la journalisation binaire est activée, vous pouvez utiliser une autre fonctionnalité de récupération intéressante appelée flashback, qui est décrite dans la section suivante.

Activer le retour en arrière

La fonctionnalité de flashback est disponible dans MariaDB, où vous pouvez restaurer les données de l'instantané précédent dans une base de données MySQL ou dans une table. Flashback utilise mysqlbinlog pour créer les instructions de restauration et il a besoin d'une image de ligne de journal binaire COMPLÈTE pour cela. Ainsi, pour utiliser cette fonctionnalité, le serveur MySQL/MariaDB doit être configuré avec les éléments suivants :

[mysqld]
...
binlog_format = ROW
binlog_row_image = FULL

Le schéma d'architecture suivant illustre la configuration du flashback sur l'un des esclaves :

Pour effectuer l'opération de flashback, vous devez d'abord déterminer la date et l'heure quand vous voulez "voir" les données, ou le fichier journal binaire et la position. Ensuite, utilisez l'indicateur --flashback avec l'utilitaire mysqlbinlog pour générer des instructions SQL afin de restaurer les données jusqu'à ce point. Dans le fichier SQL généré, vous remarquerez que les événements DELETE sont convertis en INSERT et vice versa, et qu'il permute également les parties WHERE et SET des événements UPDATE.

La ligne de commande suivante doit être exécutée sur le slave2 (configuré avec binlog_row_image=FULL) :

$ mysqlbinlog --flashback --start-datetime="2020-02-17 01:30:00"  /var/lib/mysql/mysql-bin.000028 -v --database=shop --table=products > flashback_to_2020-02-17_013000.sql

Ensuite, détachez slave2 de la chaîne de réplication car nous allons la casser et utiliser le serveur pour restaurer nos données :

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;

Enfin, importez le fichier SQL généré dans le serveur MariaDB pour la boutique de bases de données sur slave2 :

$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sql

Lorsque ce qui précède est appliqué, le tableau "produits" sera à l'état de 2020-02-17 01:30:00. Techniquement, le fichier SQL généré peut être appliqué aux serveurs MariaDB et MySQL. Vous pouvez également transférer le binaire mysqlbinlog depuis le serveur MariaDB afin de pouvoir utiliser la fonction de flashback sur un serveur MySQL. Cependant, la mise en œuvre de MySQL GTID est différente de celle de MariaDB. Ainsi, la restauration du fichier SQL nécessite que vous désactiviez MySQL GTID.

Quelques avantages de l'utilisation du flashback sont que vous n'avez pas besoin d'arrêter le serveur MySQL/MariaDB pour effectuer cette opération. Lorsque la quantité de données à restaurer est faible, le processus de flashback est beaucoup plus rapide que la récupération des données à partir d'une sauvegarde complète.

Enregistrer toutes les requêtes de base de données

Le journal général capture essentiellement chaque instruction SQL exécutée par le client sur le serveur MySQL. Cependant, cela pourrait ne pas être une décision populaire sur un serveur de production occupé en raison de l'impact sur les performances et de la consommation d'espace. Si les performances sont importantes, le journal binaire a la priorité la plus élevée pour être activé. Le journal général peut être activé pendant l'exécution en exécutant les commandes suivantes :

mysql> SET global general_log_file='/tmp/mysql.log'; 
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;

Vous pouvez également définir la sortie générale du journal sur une table :

mysql> SET global log_output = 'table';

Vous pouvez ensuite utiliser l'instruction SELECT standard sur la table mysql.general_log pour récupérer les requêtes. Attendez-vous à un peu plus d'impact sur les performances lors de l'exécution avec cette configuration, comme indiqué dans cet article de blog.

Sinon, vous pouvez utiliser des outils de surveillance externes capables d'effectuer un échantillonnage et une surveillance des requêtes afin de pouvoir filtrer et auditer les requêtes qui arrivent sur le serveur. ClusterControl peut être utilisé pour collecter et résumer toutes vos requêtes, comme illustré dans les captures d'écran suivantes où nous filtrons toutes les requêtes contenant la chaîne DELETE :

Des informations similaires sont également disponibles sur la page des principales requêtes de ProxySQL (si votre application est connexion via ProxySQL):

Ceci peut être utilisé pour suivre les modifications récentes apportées au serveur de base de données et peut également être utilisé à des fins d'audit.

Conclusion

Vos serveurs MySQL et MariaDB doivent être bien protégés à tout moment car ils contiennent généralement des données sensibles recherchées par les attaquants. Vous pouvez également utiliser ClusterControl pour gérer les aspects de sécurité de vos serveurs de base de données, comme le montre cet article de blog, Comment sécuriser vos bases de données Open Source avec ClusterControl.