{"id":1420,"date":"2026-10-31T11:03:56","date_gmt":"2026-10-31T10:03:56","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=1420"},"modified":"2026-10-31T11:04:01","modified_gmt":"2026-10-31T10:04:01","slug":"rotacion-de-credenciales-base-de-datos-ispconfig","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/es\/2026\/10\/31\/rotacion-de-credenciales-base-de-datos-ispconfig\/","title":{"rendered":"Rotaci\u00f3n de credenciales de base de datos tras una brecha en ISPConfig"},"content":{"rendered":"\n

Roto las credenciales en el momento en que sospecho una brecha. No despu\u00e9s de confirmarla. La rotaci\u00f3n de credenciales de base de datos en un servidor ISPConfig suena a mantenimiento rutinario. Deja de ser rutinaria el d\u00eda que encuentras una web shell en un sitio alojado. O un archivo de configuraci\u00f3n que no puedes explicar, guardado en una copia de seguridad p\u00fablica. En ese momento, cada contrase\u00f1a vinculada a esa base de datos tiene que ser nueva. Verificada. Documentada. No simplemente asumida como correcta.<\/p>\n\n\n\n

\"rotaci\u00f3n<\/figure>\n\n\n\n

\u00bfCu\u00e1ndo deja de ser opcional la rotaci\u00f3n de credenciales?<\/h2>\n\n\n\n

Hay unos pocos escenarios que se repiten lo suficiente como para mantener siempre listo un plan de rotaci\u00f3n. Prefiero no improvisarlo bajo presi\u00f3n.<\/p>\n\n\n\n

Un plugin o CMS de un sitio alojado se ve comprometido. Escrib\u00ed sobre un caso real en este tipo de servidor en PHP2Shell: c\u00f3mo protej\u00ed los servidores a la espera del parche<\/a>. Era una vulnerabilidad de PHP que permit\u00eda a un atacante instalar una web shell antes de que existiera el parche. Una vez que una web shell se ejecuta bajo un usuario de hosting, a menudo puede leer el propio config.inc.php de ese sitio. En un servidor ISPConfig compartido, ese archivo est\u00e1 junto a las credenciales de la propia base de datos del panel de control. No solo la credencial que el atacante realmente buscaba.<\/p>\n\n\n\n

Un archivo de configuraci\u00f3n termina donde no deber\u00eda. Un archivo de copia de seguridad olvidado en una carpeta p\u00fablica. Un repositorio subido con un archivo suelto que no deb\u00eda estar ah\u00ed. Un log m\u00e1s legible de lo que nadie pretend\u00eda. config.inc.php y mysql_clientdb.conf no tienen nada que hacer en ninguno de esos lugares. Los errores ocurren igualmente, incluidos los m\u00edos.<\/p>\n\n\n\n

Un administrador de sistemas deja el equipo. Por amistosa que sea la salida, las credenciales de base de datos compartidas que esa persona tuvo son credenciales en las que ya no conf\u00edo del todo. La confianza no se transfiere autom\u00e1ticamente cuando alguien se va.<\/p>\n\n\n\n

Una intrusi\u00f3n sospechada, incluso sin confirmar. Este caso es el m\u00e1s dif\u00edcil de explicar a quien nunca ha administrado un servidor bajo sospecha de ataque. No esperas a tener pruebas antes de actuar. Asumes el compromiso y rotas. Una rotaci\u00f3n innecesaria cuesta una tarde. Una que se omite, tras una brecha real, puede costar todos los sitios que alberga el servidor.<\/p>\n\n\n\n

Por qu\u00e9 la rotaci\u00f3n de credenciales de base de datos manual es tan propensa a errores<\/h2>\n\n\n\n

La primera vez que rot\u00e9 a mano las credenciales de base de datos de ISPConfig, subestim\u00e9 cu\u00e1ntos archivos estaban involucrados. Todos tienen que cambiar juntos, o algo se rompe silenciosamente unas horas despu\u00e9s.<\/p>\n\n\n\n

Est\u00e1 config.inc.php en el lado del servidor, y una segunda copia en el lado de la interfaz. Ambas necesitan los mismos valores nuevos. Est\u00e1 mysql_clientdb.conf, que ISPConfig lee para gestionar la propia base de datos de cada sitio alojado, no solo su propio mantenimiento interno. Dovecot, Pure-FTPd y Postfix mantienen cada uno su propia copia de algunas de las mismas credenciales. El correo y el FTP pueden dejar de autenticar en silencio si actualizas el usuario de la base de datos y te olvidas de solo uno de esos tres.<\/p>\n\n\n\n

Despu\u00e9s est\u00e1 la topolog\u00eda Master\/Slave que usan algunas de mis configuraciones. Un nodo Slave se autentica contra la base de datos de su Master a trav\u00e9s de la red, con una contrase\u00f1a separada. Esa contrase\u00f1a tiene que rotarse en el propio Master, no solo localmente. Si te equivocas en el orden, un Slave puede quedar bloqueado fuera del mismo Master del que se supone que debe replicar.<\/p>\n\n\n\n

Nada de eso es dif\u00edcil a nivel conceptual. Son muchos archivos. Varios servicios que reiniciar, en un orden sensato. Casi ninguna tolerancia a un error de tecleo, sobre todo mientras lo haces bajo presi\u00f3n, justo despu\u00e9s de encontrar algo que no quer\u00edas encontrar. Esa combinaci\u00f3n es exactamente la raz\u00f3n por la que la rotaci\u00f3n de credenciales de base de datos se sent\u00eda m\u00e1s arriesgada a mano de lo que la tarea deber\u00eda ser. Por eso escrib\u00ed reset_DB_password.sh, despu\u00e9s de vivir el problema yo mismo m\u00e1s de una vez.<\/p>\n\n\n\n

Qu\u00e9 hace realmente reset_DB_password.sh<\/h2>\n\n\n\n

reset_DB_password.sh detecta si el nodo es Standalone, Master o Slave. Luego ejecuta solo las fases que ese rol necesita.<\/p>\n\n\n\n

La Fase A rota la contrase\u00f1a local de root de MySQL. Es la contrase\u00f1a que el propio ISPConfig usa para gestionar la base de datos de cada sitio alojado. El script actualiza mysql_clientdb.conf para que coincida con el nuevo valor.<\/p>\n\n\n\n

La Fase B rota la contrase\u00f1a del usuario de control ispconfig. Actualiza config.inc.php tanto en el lado del servidor como en el de la interfaz. Despu\u00e9s actualiza las credenciales correspondientes dentro de Dovecot, Pure-FTPd y Postfix. As\u00ed, el correo y el FTP siguen autenticando sin un paso manual aparte por otros tres archivos de configuraci\u00f3n.<\/p>\n\n\n\n

La Fase C se ejecuta solo en un Slave. Se conecta de forma remota a la base de datos del Master. Rota ah\u00ed la contrase\u00f1a del usuario Slave, y despu\u00e9s actualiza dbmaster_password localmente, para que la replicaci\u00f3n siga autenticando correctamente con el nuevo valor.<\/p>\n\n\n\n

Despu\u00e9s de la Fase B, el script ofrece reiniciar Dovecot, Pure-FTPd y Postfix por ti. Casi siempre digo que s\u00ed. Una rotaci\u00f3n de credenciales que deja un servicio de correo funcionando con la contrase\u00f1a antigua no est\u00e1 terminada, solo est\u00e1 callada sobre estar rota. Reiniciar en la misma ejecuci\u00f3n, justo despu\u00e9s de cambiar los archivos de configuraci\u00f3n, mantiene todo dentro de una \u00fanica ventana de mantenimiento corta. Evita as\u00ed tres ventanas descubiertas por separado m\u00e1s tarde.<\/p>\n\n\n\n

Copias de seguridad antes de cambiar nada<\/h2>\n\n\n\n

Antes de tocar un solo archivo, el script hace una copia completa con rsync de \/usr\/local\/ispconfig\/ en una carpeta con marca de tiempo. Tambi\u00e9n intenta un mysqldump no bloqueante de las bases de datos mysql y dbispconfig. No bloqueante a prop\u00f3sito: prefiero terminar una rotaci\u00f3n de credenciales antes que quedarme esperando un dump atascado por alguna raz\u00f3n ajena. Cada archivo de configuraci\u00f3n que edita recibe primero su propia copia .bak, antes de que se reemplace ninguna cadena dentro de \u00e9l.<\/p>\n\n\n\n

Nada de eso sustituye una estrategia de copias de seguridad independiente. Sigo haciendo un snapshot separado, o una copia de seguridad completa, antes de ejecutar esto en cualquier servidor que realmente importe. El propio descargo de responsabilidad del script dice lo mismo, de forma m\u00e1s directa de lo que yo lo acabo de decir.<\/p>\n\n\n\n

Primero en modo de prueba, siempre<\/h2>\n\n\n\n

Cada fase pide confirmaci\u00f3n antes de cambiar nada. –dry-run simula una ejecuci\u00f3n completa sin tocar un solo archivo. Uso dry-run primero en cada servidor, siempre. Incluso en los que ya he rotado credenciales antes, y creo conocer bien. –skip-local-root omite la Fase A, para cuando solo hay que rotar la contrase\u00f1a del usuario de control. –role=master o –role=slave anula la detecci\u00f3n autom\u00e1tica, para el caso poco frecuente en que no lee correctamente por s\u00ed solo la topolog\u00eda de un servidor.<\/p>\n\n\n\n

Las contrase\u00f1as que genera tienen 32 caracteres, solo letras y n\u00fameros. Suficientemente largas para resistir intentos de adivinarlas. Suficientemente simples para que los propios parsers de MySQL y PHP nunca tropiecen con un s\u00edmbolo suelto en una cadena de conexi\u00f3n. He probado el script en ISPConfig 3.3.1p1. No lo he ejecutado contra ramas m\u00e1s antiguas o m\u00e1s nuevas. No asumir\u00eda un comportamiento id\u00e9ntico ah\u00ed, sin comprobarlo yo mismo antes.<\/p>\n\n\n\n

El rol de un nodo no siempre es obvio a simple vista, sobre todo en un servidor que heredaste en lugar de construir t\u00fa mismo. Por eso existe –role, y por eso vale la pena leer l\u00ednea por l\u00ednea la salida de dry-run la primera vez, no solo echarle un vistazo. Prefiero pasar dos minutos confirmando que un Slave es realmente un Slave que descubrirlo de la peor manera a mitad de la rotaci\u00f3n.<\/p>\n\n\n\n

Lo que te dir\u00eda antes de que lo ejecutes<\/h2>\n\n\n\n

Aviso<\/strong>: el script se proporciona tal cual, con fines informativos. Su uso es bajo tu exclusiva responsabilidad: no asumo ninguna responsabilidad por p\u00e9rdida de datos, interrupciones del servicio, o cualquier error provocado por un uso incorrecto, una modificaci\u00f3n del c\u00f3digo, o un contexto distinto al que yo mismo utilizo. Haz siempre una copia de seguridad independiente o un snapshot de la VM antes de ejecutarlo en producci\u00f3n, al margen de lo que ya capture por ti el propio paso de backup del script.<\/p>\n\n\n\n

Es software libre. Puedes redistribuirlo y modificarlo, con atribuci\u00f3n a m\u00ed como autor original. El c\u00f3digo de reset_DB_password.sh, y el resto de la colecci\u00f3n ispconfig-fast-tools, est\u00e1 en GitHub en github.com\/matteocisilino\/ispconfig-fast-tools<\/a>.<\/p>\n\n\n\n

La rotaci\u00f3n de credenciales de base de datos es un h\u00e1bito, no una tarea de limpieza<\/h2>\n\n\n\n

La rotaci\u00f3n de credenciales de base de datos tras una brecha confirmada es simplemente respuesta a incidentes competente. La mayor\u00eda de administradores lo har\u00eda sin que se lo repitieran dos veces. El h\u00e1bito m\u00e1s dif\u00edcil es hacerlo tras una simplemente sospechada, antes de que nadie tenga pruebas. Esa es la \u00fanica versi\u00f3n del plan que realmente limita el da\u00f1o, mientras todav\u00eda es limitable. Un script que ejecuta las fases correctas seg\u00fan el rol del servidor, y que hace sus propias copias de seguridad primero. Adem\u00e1s, me permite probarlo todo en modo dry-run antes de tocar nada real. Eso es lo que hace que el h\u00e1bito sea pr\u00e1ctico un martes por la noche, en lugar de te\u00f3rico en una entrada de blog.<\/p>\n\n\n\n

ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix y los dem\u00e1s nombres mencionados son marcas registradas de sus respectivos propietarios. Se usan \u00fanicamente para identificar los productos.<\/p>\n","protected":false},"excerpt":{"rendered":"

Por qu\u00e9 la rotaci\u00f3n de credenciales de base de datos urge tras una brecha en ISPConfig, y c\u00f3mo un script en tres fases la gestiona con copias de seguridad.<\/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":[364],"tags":[374,384,295,545,544,343],"class_list":["post-1420","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-servidores-bases-de-datos","tag-gestion-de-servidores","tag-ispconfig-es","tag-mysql-es","tag-respuesta-a-incidentes","tag-rotacion-de-credenciales","tag-script-de-bash"],"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