_ 19/12/2022

Audit de configuration d’un serveur MySQL : les quatre points à retenir.

Une bonne configuration est le premier pilier de défense contre les attaques informatiques. D’après l’OWASP [1], une mauvaise configuration est placée au cinquième rang des risques de sécurité les plus critiques pour les applications Web avec une place de plus par rapport à la version précédente de 2017.

Un audit de configuration est un audit spécifique qui vise à comparer la configuration d’un système, d’un service ou d’une solution par rapport à une configuration jugée sûre. D’après l’ANSSI [2], un audit de configuration a pour vocation de vérifier la mise en œuvre de pratiques de sécurité conformes à l’état de l’art et aux exigences et règles internes de l’audité en matière de configuration des dispositifs matériels et logiciels déployés au sein de son système d’information. Afin de garantir une configuration robuste en accord avec des normes et référentiels, il est fortement recommandé pour une entreprise d’effectuer un audit de configuration.

Fort de notre expertise en audits techniques dont font partie les audits de configuration, nous exposons dans cet article quatre points de durcissement fortement recommandés pour vos serveurs MySQL. Un utilisateur expérimenté peut vérifier les guides du CIS et les autres références pour un durcissement complet.

1. Vérifier que le serveur MySQL est bien à jour

Garder son infrastructure à jour est indispensable pour assurer sa sécurité. Durant les dix dernières années, plusieurs vulnérabilités ont été publiées avec un impact critique sur les serveurs MySQL. Par exemple, une vulnérabilité de niveau critique portant la référence CVE-2016-6662 [3] a affecté plusieurs versions d’Oracle MySQL, et les bases de données MariaDB et Percona DB dérivées de MySQL en 2016. Cette CVE peut être exploitée pour obtenir un accès « root » aux serveurs MySQL exposés.

Garder votre serveur MySQL à jour permet d’éviter que des failles soient exploitées pour nuire à votre infrastructure. Pour cela, exécutez l’instruction SQL suivante pour identifier la version du serveur MySQL puis comparez la avec les publications de sécurité d’Oracle et/ou du système d’exploitation si l’OS packages est utilisé.

SHOW VARIABLES WHERE Variable_name LIKE "version";

2. Définir de bonnes politiques de mots de passe

Une autre mesure de sécurité universelle est d’avoir mis en œuvre une solide politique de mots de passe. Eh oui, utiliser “password” comme mot de passe de l’utilisateur root de votre base de données MySQL est une très mauvaise idée. En général, il est recommandé d’avoir des mots de passe de plus de 8 caractères, de mélanger lettres minuscules, majuscules, chiffres et caractères spéciaux et de ne pas former de mots facilement reconnaissables (“P@ssW0rD” est une mauvaise idée).

Bien évidemment, il faut s’assurer que chaque utilisateur possède un mot de passe solide, car c’est un point de vigilance important pour une base de données MySQL où des utilisateurs peuvent être créés sans mot de passe. Pour le vérifier, il vous suffit de lancer la commande suivante :

SELECT User, host FROM mysql.user WHERE (LENGTH(authentication_string) = 0 OR authentication_string IS NULL) 
OR (plugin='sha256_password' AND LENGTH(authentication_string) = 0);

Tout résultat renvoyé indique un utilisateur sans mot de passe. Dans notre cas, l’utilisateur « nopass » identifié est sans mot de passe.

L’expiration des mots de passe dans les serveurs MySQL est définie par la valeur default_password_lifetime. Si votre mot de passe est compromis et/ou n’est jamais changé, un attaquant en le récupérant pourra l’utiliser pour accéder à vos bases de données. Afin de connaître la durée de vie de vos mots de passe, il vous suffit d’exécuter la commande suivante :

SHOW VARIABLES LIKE 'default_password_lifetime';

Pour la modifier, il faut utiliser la commande ci-après et remplacer 365 par un nombre de jours avant expiration :

SET GLOBAL default_password_lifetime=365;

3. Vérifier que le privilège « FILE » n’est pas accordé aux utilisateurs standards.

La gestion des utilisateurs, rôles, autorisations et permissions est un élément clé de la sécurité des bases de données comme dans MySQL. Par exemple, le privilège « FILE » est utilisé pour autoriser ou interdire un utilisateur de lire et d’écrire des fichiers sur le serveur. Tout utilisateur disposant du droit « FILE » a la possibilité de :

Lire les fichiers du système de fichiers local qui sont lisibles par le serveur MySQL
Écrire des fichiers sur le système de fichiers local où le serveur MySQL a un accès en écriture.

Le privilège « FILE » peut se révéler dangereux, c’est pourquoi il faut en limiter l’utilisation et l’octroyer uniquement aux utilisateurs le nécessitant.

Afin de vérifier quel utilisateur possède ce droit, il suffit d’exécuter cette commande :

SELECT GRANTEE FROM INFORMATION_SCHEMA.USER_PRIVILEGES WHERE PRIVILEGE_TYPE = 'FILE';

Si des utilisateurs identifiés possèdent le privilège « FILE », alors il convient de vérifier que ces mêmes utilisateurs ont vraiment besoin de cette permission.

La commande suivante est utilisée pour enlever cette permission à un utilisateur <user> :

REVOKE FILE ON *.* FROM '<user>';

4. Vérifier que l’option « log-raw » est désactivée

L’option log-raw détermine si les mots de passe sont réécrits par le serveur afin de ne pas apparaître en clair dans les fichiers journaux. Si l’option log-raw est activée, les mots de passe sont écrits en clair dans les différents fichiers de journalisation. Désactiver cette option permet d’éviter les fuites de données confidentielles. Cette option peut se révéler utile dans un environnement de test ou en sessions de débogage. Cependant, elle peut être désactivée via l’option log-raw. Il est donc nécessaire de s’assurer de la bonne configuration de cet élément via le fichier de configuration de MySQL : my.cnf.

Le fichier my.cnf (ou my.ini sous Windows) est le fichier de configuration du serveur MySQL. Les programmes fournis par MySQL (mysqld, mysqldump, mysql…) utilisent ce fichier pour chercher leurs directives. Sous Linux, ce fichier est souvent localisé dans /etc/, /etc/mysql/ et ~/. Un utilisateur peut localiser l’emplacement de ce fichier via la commande suivante :

$ mysqladmin --help

Pour vérifier cette recommandation, il faut vérifier que l’option log-raw est présente avec la valeur OFF dans le fichier my.cnf.

Au vu des points présentés ci-dessus, la réalisation d’un audit de configuration s’avère indispensable pour réduire la surface d’attaque et obtenir une garantie supplémentaire sur la sécurité de son système d’information.

CoESSI a développé à cet effet CoACT : CoESSI Configuration Audit Toolbox, une boîte à outils pour réaliser des audits de configuration de diverses cibles.

L’objectif principal de CoaACT vise à extraire puis comparer la configuration d’un système ou d’un service par rapport à une liste de contrôle de configuration jugée sure, ou recommandée par les bonnes pratiques de sécurité. CoACT vérifie et évalue point par point la configuration analysée avec la configuration cible recommandée, en justifiant la différence entre les deux configurations, les moyens de remédier aux écarts constatés, ainsi que les raisons de changer la configuration initiale. Afin de toujours garantir un niveau de sécurité élevé, CoACT s’appuie sur des références dédiées au domaine de l’audit de configuration.

Une fois les cibles identifiées, l’analyse de la configuration peut être menée selon deux méthodes pour produire des résultats sous forme de texte ou d’autres formats exploitables par nos auditeurs :

Automatiquement, à partir d’un accès privilégié à la cible. Une extraction menée « à chaud », en accédant directement à une interface utilisateur de la cible.
Sur un ensemble de fichiers de configuration fournis par le client. Ces fichiers forment les arguments d’entrées de l’outil CoACT durant l’analyse.