{"id":1416,"date":"2026-10-31T11:03:56","date_gmt":"2026-10-31T10:03:56","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=1416"},"modified":"2026-10-31T11:03:59","modified_gmt":"2026-10-31T10:03:59","slug":"rotation-identifiants-base-de-donnees-faille-ispconfig","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/fr\/2026\/10\/31\/rotation-identifiants-base-de-donnees-faille-ispconfig\/","title":{"rendered":"Rotation des identifiants de base de donn\u00e9es apr\u00e8s une faille ISPConfig"},"content":{"rendered":"\n

Je lance la rotation des identifiants d\u00e8s que je suspecte une faille. Pas apr\u00e8s l’avoir confirm\u00e9e. La rotation des identifiants de base de donn\u00e9es sur un serveur ISPConfig a l’air d’une maintenance de routine. Elle cesse de l’\u00eatre le jour o\u00f9 vous trouvez un web shell sur un site h\u00e9berg\u00e9. Ou un fichier de configuration que vous ne savez pas expliquer, pos\u00e9 dans une sauvegarde publique. \u00c0 ce moment-l\u00e0, chaque mot de passe li\u00e9 \u00e0 cette base de donn\u00e9es doit \u00eatre nouveau. V\u00e9rifi\u00e9. Document\u00e9. Pas seulement suppos\u00e9 correct.<\/p>\n\n\n\n

\"rotation<\/figure>\n\n\n\n

Quand la rotation des identifiants cesse-t-elle d’\u00eatre optionnelle ?<\/h2>\n\n\n\n

Quelques sc\u00e9narios reviennent assez souvent pour que je garde un plan de rotation pr\u00eat \u00e0 l’avance. Je pr\u00e9f\u00e8re ne pas en improviser un sous pression.<\/p>\n\n\n\n

Un plugin ou un CMS sur un site h\u00e9berg\u00e9 se fait compromettre. J’ai racont\u00e9 un cas r\u00e9el sur ce type de serveur dans PHP2Shell : comment j’ai prot\u00e9g\u00e9 mes serveurs en attendant le correctif<\/a>, une vuln\u00e9rabilit\u00e9 PHP qui permettait \u00e0 un attaquant de d\u00e9poser un web shell avant qu’un correctif n’existe. Une fois qu’un web shell tourne sous un utilisateur d’h\u00e9bergement, il peut souvent lire le config.inc.php propre \u00e0 ce site. Sur un serveur ISPConfig partag\u00e9, ce fichier se trouve juste \u00e0 c\u00f4t\u00e9 des identifiants de la base de donn\u00e9es du panneau de contr\u00f4le lui-m\u00eame. Pas seulement celui que l’attaquant visait au d\u00e9part.<\/p>\n\n\n\n

Un fichier de configuration se retrouve l\u00e0 o\u00f9 il ne devrait pas \u00eatre. Une archive de sauvegarde oubli\u00e9e dans un dossier public. Un d\u00e9p\u00f4t pouss\u00e9 avec un fichier \u00e9gar\u00e9 dedans. Un journal plus lisible que pr\u00e9vu. config.inc.php et mysql_clientdb.conf n’ont rien \u00e0 faire dans aucun de ces endroits. Les erreurs arrivent malgr\u00e9 tout, y compris les miennes.<\/p>\n\n\n\n

Un administrateur syst\u00e8me quitte l’\u00e9quipe. Quel que soit le ton du d\u00e9part, les identifiants de base de donn\u00e9es partag\u00e9s qu’il d\u00e9tenait ne m’inspirent plus une confiance totale. La confiance ne se transmet pas automatiquement quand quelqu’un passe la porte.<\/p>\n\n\n\n

Une intrusion suspect\u00e9e, m\u00eame non confirm\u00e9e. C’est le cas le plus difficile \u00e0 expliquer \u00e0 qui n’a jamais g\u00e9r\u00e9 un serveur sous suspicion d’attaque. On n’attend pas la preuve avant d’agir. On pr\u00e9sume la compromission et on lance la rotation. Une rotation inutile co\u00fbte un apr\u00e8s-midi. Une rotation saut\u00e9e, apr\u00e8s une faille r\u00e9elle, peut co\u00fbter tous les sites h\u00e9berg\u00e9s par le serveur.<\/p>\n\n\n\n

Pourquoi la rotation manuelle des identifiants est si sujette aux erreurs<\/h2>\n\n\n\n

La premi\u00e8re fois que j’ai fait la rotation des identifiants d’ISPConfig \u00e0 la main, j’ai sous-estim\u00e9 le nombre de fichiers concern\u00e9s. Ils doivent tous changer ensemble, sinon quelque chose casse discr\u00e8tement quelques heures plus tard.<\/p>\n\n\n\n

Il y a config.inc.php c\u00f4t\u00e9 serveur, et une seconde copie c\u00f4t\u00e9 interface. Les deux doivent recevoir les m\u00eames nouvelles valeurs. Il y a mysql_clientdb.conf, que ISPConfig lit pour g\u00e9rer la base de donn\u00e9es de chaque site h\u00e9berg\u00e9, pas seulement son propre m\u00e9nage 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 \u00e0 jour l’utilisateur de la base de donn\u00e9es et oubliez un seul de ces trois services.<\/p>\n\n\n\n

Il y a ensuite la topologie Master\/Slave de certaines de mes installations. Un n\u0153ud Slave s’authentifie aupr\u00e8s de la base de donn\u00e9es de son Master via le r\u00e9seau, avec un mot de passe distinct. Ce mot de passe doit \u00eatre tourn\u00e9 sur le Master lui-m\u00eame, pas seulement en local. Si l’ordre est mauvais, un Slave peut se retrouver verrouill\u00e9 hors du Master m\u00eame qu’il est cens\u00e9 r\u00e9pliquer.<\/p>\n\n\n\n

Rien de tout cela n’est conceptuellement difficile. C’est juste beaucoup de fichiers. Plusieurs services \u00e0 red\u00e9marrer, dans un ordre sens\u00e9. Presque aucune tol\u00e9rance pour une faute de frappe, surtout sous pression, juste apr\u00e8s avoir trouv\u00e9 quelque chose que vous ne vouliez pas trouver. Cette combinaison explique pourquoi la rotation des identifiants paraissait toujours plus risqu\u00e9e \u00e0 la main que la t\u00e2che elle-m\u00eame ne devrait l’\u00eatre. C’est pour cette raison que j’ai \u00e9crit reset_DB_password.sh, apr\u00e8s avoir v\u00e9cu ce probl\u00e8me moi-m\u00eame plus d’une fois.<\/p>\n\n\n\n

Ce que reset_DB_password.sh fait r\u00e9ellement<\/h2>\n\n\n\n

reset_DB_password.sh d\u00e9tecte si le n\u0153ud est Standalone, Master ou Slave. Il ex\u00e9cute ensuite uniquement les phases que ce r\u00f4le exige.<\/p>\n\n\n\n

La phase A tourne le mot de passe root local de MySQL. C’est le mot de passe qu’ISPConfig utilise lui-m\u00eame pour g\u00e9rer la base de donn\u00e9es de chaque site h\u00e9berg\u00e9. Le script met \u00e0 jour mysql_clientdb.conf avec la nouvelle valeur.<\/p>\n\n\n\n

La phase B tourne le mot de passe de l’utilisateur de contr\u00f4le ispconfig. Elle met \u00e0 jour config.inc.php c\u00f4t\u00e9 serveur et c\u00f4t\u00e9 interface. Puis elle met \u00e0 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\u00e9mentaires.<\/p>\n\n\n\n

La phase C ne tourne que sur un Slave. Elle se connecte \u00e0 distance \u00e0 la base de donn\u00e9es du Master. Elle tourne l\u00e0 le mot de passe de l’utilisateur Slave, puis met \u00e0 jour dbmaster_password en local, pour que la r\u00e9plication continue de s’authentifier correctement avec la nouvelle valeur.<\/p>\n\n\n\n

Apr\u00e8s la phase B, le script propose de red\u00e9marrer 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\u00e9e, elle est juste silencieusement cass\u00e9e. Red\u00e9marrer dans la m\u00eame ex\u00e9cution, juste apr\u00e8s le changement des fichiers de configuration, garde tout cela dans une seule courte fen\u00eatre de maintenance au lieu de trois fen\u00eatres s\u00e9par\u00e9es d\u00e9couvertes plus tard.<\/p>\n\n\n\n

Des sauvegardes avant tout changement<\/h2>\n\n\n\n

Avant de toucher le moindre fichier, le script fait une copie rsync compl\u00e8te de \/usr\/local\/ispconfig\/ dans un dossier horodat\u00e9. Il tente aussi un mysqldump non bloquant des bases mysql et dbispconfig. Non bloquant volontairement : je pr\u00e9f\u00e8re terminer une rotation d’identifiants plut\u00f4t qu’attendre un dump bloqu\u00e9 pour une raison qui n’a rien \u00e0 voir. Chaque fichier de configuration qu’il modifie re\u00e7oit sa propre copie .bak avant qu’une seule cha\u00eene \u00e0 l’int\u00e9rieur ne soit remplac\u00e9e.<\/p>\n\n\n\n

Rien de tout cela ne remplace une strat\u00e9gie de sauvegarde ind\u00e9pendante. Je prends toujours un snapshot s\u00e9par\u00e9, ou une sauvegarde compl\u00e8te, avant de lancer ceci sur un serveur qui compte vraiment. Le propre avertissement du script dit la m\u00eame chose, de fa\u00e7on plus directe que je ne viens de le faire.<\/p>\n\n\n\n

Toujours un dry run d’abord<\/h2>\n\n\n\n

Chaque phase demande une confirmation avant de toucher \u00e0 quoi que ce soit. –dry-run simule une ex\u00e9cution compl\u00e8te sans toucher un seul fichier. J’utilise dry-run en premier sur chaque serveur, chaque fois. M\u00eame sur ceux dont j’ai d\u00e9j\u00e0 tourn\u00e9 les identifiants, et que je crois bien conna\u00eetre. –skip-local-root saute la phase A, pour quand seul le mot de passe de l’utilisateur de contr\u00f4le doit changer. –role=master ou –role=slave remplace la d\u00e9tection automatique, pour le cas rare o\u00f9 elle ne lit pas correctement la topologie d’un serveur.<\/p>\n\n\n\n

Les mots de passe qu’il g\u00e9n\u00e8re comptent 32 caract\u00e8res, lettres et chiffres uniquement. Assez longs pour r\u00e9sister \u00e0 une tentative de deviner. Assez simples pour que les parseurs de MySQL et de PHP ne tr\u00e9buchent jamais sur un symbole \u00e9gar\u00e9 dans une cha\u00eene de connexion. J’ai test\u00e9 le script sur ISPConfig 3.3.1p1. Je ne l’ai pas lanc\u00e9 sur des branches plus anciennes ou plus r\u00e9centes. Je ne pr\u00e9sumerais pas un comportement identique l\u00e0-bas, sans v\u00e9rifier moi-m\u00eame d’abord.<\/p>\n\n\n\n

Le r\u00f4le d’un n\u0153ud n’est pas toujours \u00e9vident au premier coup d’\u0153il, surtout sur un serveur dont vous avez h\u00e9rit\u00e9 plut\u00f4t que celui que vous avez construit vous-m\u00eame. C’est pour cela que –role existe, et pourquoi la sortie du dry-run vaut la peine d’\u00eatre lue ligne par ligne la premi\u00e8re fois, pas survol\u00e9e. Je pr\u00e9f\u00e8re passer deux minutes \u00e0 confirmer qu’un Slave est vraiment un Slave plut\u00f4t que de le d\u00e9couvrir \u00e0 la dure en plein milieu de la rotation.<\/p>\n\n\n\n

Ce que je vous dirais avant de l’ex\u00e9cuter<\/h2>\n\n\n\n

Avertissement<\/strong> : le script est fourni tel quel, \u00e0 titre informatif. Son utilisation se fait enti\u00e8rement \u00e0 vos risques : je n’assume aucune responsabilit\u00e9 pour une perte de donn\u00e9es, une interruption de service, ou toute erreur caus\u00e9e par un usage incorrect ou par un contexte diff\u00e9rent de celui dans lequel je l’utilise moi-m\u00eame. Gardez toujours une sauvegarde ind\u00e9pendante ou un snapshot de VM avant de l’ex\u00e9cuter en production, quoi que la propre \u00e9tape de sauvegarde du script capture d\u00e9j\u00e0 pour vous.<\/p>\n\n\n\n

C’est un logiciel libre. Vous pouvez le redistribuer et le modifier, avec attribution \u00e0 moi comme auteur original. Le code source de reset_DB_password.sh, et le reste de la collection ispconfig-fast-tools, est sur GitHub \u00e0 l’adresse github.com\/matteocisilino\/ispconfig-fast-tools<\/a>.<\/p>\n\n\n\n

La rotation des identifiants de base de donn\u00e9es est une habitude, pas une t\u00e2che de nettoyage<\/h2>\n\n\n\n

La rotation des identifiants de base de donn\u00e9es apr\u00e8s une faille confirm\u00e9e, c’est simplement une r\u00e9ponse aux incidents comp\u00e9tente. La plupart des administrateurs le feraient sans qu’on ait \u00e0 le leur r\u00e9p\u00e9ter. L’habitude la plus difficile, c’est de le faire apr\u00e8s une faille simplement suspect\u00e9e, avant d’avoir la moindre preuve. C’est la seule version du plan qui limite vraiment les d\u00e9g\u00e2ts, tant qu’ils sont encore limitables. Un script qui ex\u00e9cute les bonnes phases selon le r\u00f4le d’un serveur, prend ses propres sauvegardes d’abord, et me laisse faire un dry-run complet avant de toucher \u00e0 quoi que ce soit de r\u00e9el. Voil\u00e0 ce qui rend cette habitude praticable un mardi soir, plut\u00f4t que th\u00e9orique dans un article de blog.<\/p>\n\n\n\n

ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix et les autres noms mentionn\u00e9s sont des marques d\u00e9pos\u00e9es de leurs propri\u00e9taires respectifs. Ils sont utilis\u00e9s uniquement pour identifier les produits.<\/p>\n","protected":false},"excerpt":{"rendered":"

Apr\u00e8s une faille ISPConfig, je lance la rotation des identifiants de base de donn\u00e9es avec reset_DB_password.sh : d\u00e9tection du r\u00f4le, sauvegardes automatiques et dry-run obligatoire.<\/p>\n","protected":false},"author":1,"featured_media":1411,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"wpai_generated_summary":"","footnotes":""},"categories":[362],"tags":[372,382,293,541,540,341],"class_list":["post-1416","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-serveurs-bases-de-donnees","tag-gestion-de-serveurs","tag-ispconfig-fr","tag-mysql-fr","tag-reponse-aux-incidents","tag-rotation-des-identifiants","tag-script-bash-fr"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t