Je lance la rotation des identifiants dès que je suspecte une faille. Pas après l’avoir confirmée. La rotation des identifiants de base de données sur un serveur ISPConfig a l’air d’une maintenance de routine. Elle cesse de l’être le jour où vous trouvez un web shell sur un site hébergé. Ou un fichier de configuration que vous ne savez pas expliquer, posé dans une sauvegarde publique. À ce moment-là, chaque mot de passe lié à cette base de données doit être nouveau. Vérifié. Documenté. Pas seulement supposé correct.
Quand la rotation des identifiants cesse-t-elle d’être optionnelle ?
Quelques scénarios reviennent assez souvent pour que je garde un plan de rotation prêt à l’avance. Je préfère ne pas en improviser un sous pression.
Un plugin ou un CMS sur un site hébergé se fait compromettre. J’ai raconté un cas réel sur ce type de serveur dans PHP2Shell : comment j’ai protégé mes serveurs en attendant le correctif, une vulnérabilité PHP qui permettait à un attaquant de déposer un web shell avant qu’un correctif n’existe. Une fois qu’un web shell tourne sous un utilisateur d’hébergement, il peut souvent lire le config.inc.php propre à ce site. Sur un serveur ISPConfig partagé, ce fichier se trouve juste à côté des identifiants de la base de données du panneau de contrôle lui-même. Pas seulement celui que l’attaquant visait au départ.
Un fichier de configuration se retrouve là où il ne devrait pas être. Une archive de sauvegarde oubliée dans un dossier public. Un dépôt poussé avec un fichier égaré dedans. Un journal plus lisible que prévu. config.inc.php et mysql_clientdb.conf n’ont rien à faire dans aucun de ces endroits. Les erreurs arrivent malgré tout, y compris les miennes.
Un administrateur système quitte l’équipe. Quel que soit le ton du départ, les identifiants de base de données partagés qu’il détenait ne m’inspirent plus une confiance totale. La confiance ne se transmet pas automatiquement quand quelqu’un passe la porte.
Une intrusion suspectée, même non confirmée. C’est le cas le plus difficile à expliquer à qui n’a jamais géré un serveur sous suspicion d’attaque. On n’attend pas la preuve avant d’agir. On présume la compromission et on lance la rotation. Une rotation inutile coûte un après-midi. Une rotation sautée, après une faille réelle, peut coûter tous les sites hébergés par le serveur.
Pourquoi la rotation manuelle des identifiants est si sujette aux erreurs
La première fois que j’ai fait la rotation des identifiants d’ISPConfig à la main, j’ai sous-estimé le nombre de fichiers concernés. Ils doivent tous changer ensemble, sinon quelque chose casse discrètement quelques heures plus tard.
Il y a config.inc.php côté serveur, et une seconde copie côté interface. Les deux doivent recevoir les mêmes nouvelles valeurs. Il y a mysql_clientdb.conf, que ISPConfig lit pour gérer la base de données de chaque site hébergé, pas seulement son propre ménage interne. Dovecot, Pure-FTPd et Postfix conservent chacun leur propre copie de certains de ces identifiants. Le mail et le FTP peuvent cesser de s’authentifier silencieusement si vous mettez à jour l’utilisateur de la base de données et oubliez un seul de ces trois services.
Il y a ensuite la topologie Master/Slave de certaines de mes installations. Un nœud Slave s’authentifie auprès de la base de données de son Master via le réseau, avec un mot de passe distinct. Ce mot de passe doit être tourné sur le Master lui-même, pas seulement en local. Si l’ordre est mauvais, un Slave peut se retrouver verrouillé hors du Master même qu’il est censé répliquer.
Rien de tout cela n’est conceptuellement difficile. C’est juste beaucoup de fichiers. Plusieurs services à redémarrer, dans un ordre sensé. Presque aucune tolérance pour une faute de frappe, surtout sous pression, juste après avoir trouvé quelque chose que vous ne vouliez pas trouver. Cette combinaison explique pourquoi la rotation des identifiants paraissait toujours plus risquée à la main que la tâche elle-même ne devrait l’être. C’est pour cette raison que j’ai écrit reset_DB_password.sh, après avoir vécu ce problème moi-même plus d’une fois.
Ce que reset_DB_password.sh fait réellement
reset_DB_password.sh détecte si le nœud est Standalone, Master ou Slave. Il exécute ensuite uniquement les phases que ce rôle exige.
La phase A tourne le mot de passe root local de MySQL. C’est le mot de passe qu’ISPConfig utilise lui-même pour gérer la base de données de chaque site hébergé. Le script met à jour mysql_clientdb.conf avec la nouvelle valeur.
La phase B tourne le mot de passe de l’utilisateur de contrôle ispconfig. Elle met à jour config.inc.php côté serveur et côté interface. Puis elle met à jour les identifiants correspondants dans Dovecot, Pure-FTPd et Postfix, pour que le mail et le FTP continuent de s’authentifier sans passer manuellement par trois fichiers de configuration supplémentaires.
La phase C ne tourne que sur un Slave. Elle se connecte à distance à la base de données du Master. Elle tourne là le mot de passe de l’utilisateur Slave, puis met à jour dbmaster_password en local, pour que la réplication continue de s’authentifier correctement avec la nouvelle valeur.
Après la phase B, le script propose de redémarrer Dovecot, Pure-FTPd et Postfix pour vous. Je dis presque toujours oui. Une rotation d’identifiants qui laisse un service mail tourner avec l’ancien mot de passe n’est pas terminée, elle est juste silencieusement cassée. Redémarrer dans la même exécution, juste après le changement des fichiers de configuration, garde tout cela dans une seule courte fenêtre de maintenance au lieu de trois fenêtres séparées découvertes plus tard.
Des sauvegardes avant tout changement
Avant de toucher le moindre fichier, le script fait une copie rsync complète de /usr/local/ispconfig/ dans un dossier horodaté. Il tente aussi un mysqldump non bloquant des bases mysql et dbispconfig. Non bloquant volontairement : je préfère terminer une rotation d’identifiants plutôt qu’attendre un dump bloqué pour une raison qui n’a rien à voir. Chaque fichier de configuration qu’il modifie reçoit sa propre copie .bak avant qu’une seule chaîne à l’intérieur ne soit remplacée.
Rien de tout cela ne remplace une stratégie de sauvegarde indépendante. Je prends toujours un snapshot séparé, ou une sauvegarde complète, avant de lancer ceci sur un serveur qui compte vraiment. Le propre avertissement du script dit la même chose, de façon plus directe que je ne viens de le faire.
Toujours un dry run d’abord
Chaque phase demande une confirmation avant de toucher à quoi que ce soit. –dry-run simule une exécution complète sans toucher un seul fichier. J’utilise dry-run en premier sur chaque serveur, chaque fois. Même sur ceux dont j’ai déjà tourné les identifiants, et que je crois bien connaître. –skip-local-root saute la phase A, pour quand seul le mot de passe de l’utilisateur de contrôle doit changer. –role=master ou –role=slave remplace la détection automatique, pour le cas rare où elle ne lit pas correctement la topologie d’un serveur.
Les mots de passe qu’il génère comptent 32 caractères, lettres et chiffres uniquement. Assez longs pour résister à une tentative de deviner. Assez simples pour que les parseurs de MySQL et de PHP ne trébuchent jamais sur un symbole égaré dans une chaîne de connexion. J’ai testé le script sur ISPConfig 3.3.1p1. Je ne l’ai pas lancé sur des branches plus anciennes ou plus récentes. Je ne présumerais pas un comportement identique là-bas, sans vérifier moi-même d’abord.
Le rôle d’un nœud n’est pas toujours évident au premier coup d’œil, surtout sur un serveur dont vous avez hérité plutôt que celui que vous avez construit vous-même. C’est pour cela que –role existe, et pourquoi la sortie du dry-run vaut la peine d’être lue ligne par ligne la première fois, pas survolée. Je préfère passer deux minutes à confirmer qu’un Slave est vraiment un Slave plutôt que de le découvrir à la dure en plein milieu de la rotation.
Ce que je vous dirais avant de l’exécuter
Avertissement : le script est fourni tel quel, à titre informatif. Son utilisation se fait entièrement à vos risques : je n’assume aucune responsabilité pour une perte de données, une interruption de service, ou toute erreur causée par un usage incorrect ou par un contexte différent de celui dans lequel je l’utilise moi-même. Gardez toujours une sauvegarde indépendante ou un snapshot de VM avant de l’exécuter en production, quoi que la propre étape de sauvegarde du script capture déjà pour vous.
C’est un logiciel libre. Vous pouvez le redistribuer et le modifier, avec attribution à moi comme auteur original. Le code source de reset_DB_password.sh, et le reste de la collection ispconfig-fast-tools, est sur GitHub à l’adresse github.com/matteocisilino/ispconfig-fast-tools.
La rotation des identifiants de base de données est une habitude, pas une tâche de nettoyage
La rotation des identifiants de base de données après une faille confirmée, c’est simplement une réponse aux incidents compétente. La plupart des administrateurs le feraient sans qu’on ait à le leur répéter. L’habitude la plus difficile, c’est de le faire après une faille simplement suspectée, avant d’avoir la moindre preuve. C’est la seule version du plan qui limite vraiment les dégâts, tant qu’ils sont encore limitables. Un script qui exécute les bonnes phases selon le rôle d’un serveur, prend ses propres sauvegardes d’abord, et me laisse faire un dry-run complet avant de toucher à quoi que ce soit de réel. Voilà ce qui rend cette habitude praticable un mardi soir, plutôt que théorique dans un article de blog.
ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix et les autres noms mentionnés sont des marques déposées de leurs propriétaires respectifs. Ils sont utilisés uniquement pour identifier les produits.
Laisser un commentaire