{"id":1415,"date":"2026-10-31T11:03:56","date_gmt":"2026-10-31T10:03:56","guid":{"rendered":"https:\/\/www.cisilino.com\/?p=1415"},"modified":"2026-10-31T11:03:58","modified_gmt":"2026-10-31T10:03:58","slug":"ispconfig-zugangsdaten-rotieren-nach-angriff","status":"publish","type":"post","link":"https:\/\/www.cisilino.com\/de\/2026\/10\/31\/ispconfig-zugangsdaten-rotieren-nach-angriff\/","title":{"rendered":"Datenbank-Zugangsdaten-Rotation nach einem ISPConfig-Sicherheitsvorfall"},"content":{"rendered":"\n

ISPConfig-Zugangsdaten rotieren bedeutet f\u00fcr mich: handeln, sobald ich einen Einbruch vermute. Nicht erst, nachdem ich einen best\u00e4tigt habe. Datenbank-Zugangsdaten auf einem ISPConfig-Server zu rotieren klingt nach Routinewartung. Routine bleibt es nicht mehr, sobald man eine Webshell auf einer gehosteten Website findet. Oder eine Konfigurationsdatei, die man sich nicht erkl\u00e4ren kann, in einem \u00f6ffentlichen Backup. Ab diesem Punkt muss jedes Passwort, das zu diesem Datenbank-Stack geh\u00f6rt, neu sein. \u00dcberpr\u00fcft. Dokumentiert. Nicht einfach als unbedenklich angenommen.<\/p>\n\n\n\n

\"ISPConfig-Zugangsdaten<\/figure>\n\n\n\n

Wann h\u00f6rt Rotation auf, optional zu sein?<\/h2>\n\n\n\n

Ein paar Szenarien bringen das Thema regelm\u00e4\u00dfig genug zur Sprache, dass ich einen Rotationsplan daf\u00fcr bereithalte. Ich improvisiere lieber keinen unter Druck.<\/p>\n\n\n\n

Ein Plugin oder CMS auf einer gehosteten Website wird kompromittiert. \u00dcber einen echten Fall auf dieser Art von Server habe ich hier geschrieben: PHP2Shell: So habe ich meine Server bis zum Patch gesch\u00fctzt<\/a>, eine PHP-Schwachstelle, die einem Angreifer erlaubte, eine Webshell abzulegen, bevor es einen Patch gab. Sobald eine Webshell unter einem Hosting-Benutzer l\u00e4uft, kann sie oft die eigene config.inc.php dieser Website lesen. Auf einer gemeinsam genutzten ISPConfig-Box liegt diese Datei direkt neben den Zugangsdaten f\u00fcr die eigene Datenbank des Kontrollpanels. Nicht nur das eine Zugangsdatum, hinter dem der Angreifer eigentlich her war.<\/p>\n\n\n\n

Eine Konfigurationsdatei landet irgendwo, wo sie nicht hingeh\u00f6rt. Ein Backup-Archiv, das in einem \u00f6ffentlichen Ordner liegen bleibt. Ein Repository, das mit einer versehentlichen Datei gepusht wird. Ein Log, das lesbarer ist, als es sein sollte. config.inc.php und mysql_clientdb.conf haben an keinem dieser Orte etwas zu suchen. Fehler passieren trotzdem, auch mir.<\/p>\n\n\n\n

Ein Systemadministrator verl\u00e4sst das Team. Wie einvernehmlich der Abschied auch war, gemeinsam genutzte Datenbank-Zugangsdaten, die diese Person einmal hatte, sind Zugangsdaten, denen ich nicht mehr vollst\u00e4ndig vertraue. Vertrauen wird nicht automatisch \u00fcbertragen, wenn jemand zur T\u00fcr hinausgeht.<\/p>\n\n\n\n

Ein vermuteter Einbruch, selbst ein unbest\u00e4tigter. Dieser Fall l\u00e4sst sich am schwersten jemandem erkl\u00e4ren, der noch nie einen Server unter Angriffsverdacht betrieben hat. Man wartet nicht auf einen Beweis, bevor man handelt. Man geht von einer Kompromittierung aus und rotiert. Eine unn\u00f6tige Rotation kostet einen Nachmittag. Eine ausgelassene, nach einem echten Einbruch, kann jede Website kosten, die der Server hostet.<\/p>\n\n\n\n

Warum ISPConfig-Zugangsdaten rotieren von Hand so fehleranf\u00e4llig ist<\/h2>\n\n\n\n

Als ich die Datenbank-Zugangsdaten von ISPConfig zum ersten Mal von Hand rotiert habe, habe ich untersch\u00e4tzt, wie viele Dateien betroffen sind. Sie m\u00fcssen alle zusammen ge\u00e4ndert werden, sonst geht ein paar Stunden sp\u00e4ter irgendwo leise etwas kaputt.<\/p>\n\n\n\n

Es gibt config.inc.php auf der Server-Seite und eine zweite Kopie auf der Interface-Seite. Beide m\u00fcssen dieselben neuen Werte bekommen. Es gibt mysql_clientdb.conf, das ISPConfig ausliest, um die eigene Datenbank jeder gehosteten Website zu verwalten, nicht nur seine eigene Haushaltsf\u00fchrung. Dovecot, Pure-FTPd und Postfix f\u00fchren jeweils eine eigene Kopie einiger dieser Zugangsdaten. Mail und FTP k\u00f6nnen still aufh\u00f6ren, sich zu authentifizieren, wenn man den Datenbank-Benutzer aktualisiert und dabei nur eine dieser drei Dienste vergisst.<\/p>\n\n\n\n

Dann gibt es die Master\/Slave-Topologie, die einige meiner Setups verwenden. Ein Slave-Knoten authentifiziert sich \u00fcber das Netzwerk an der Datenbank seines Masters, mit einem separaten Passwort. Dieses Passwort muss auf dem Master selbst rotiert werden, nicht nur lokal. Bringt man die Reihenfolge durcheinander, kann sich ein Slave vom eigenen Master aussperren, von dem er eigentlich replizieren soll.<\/p>\n\n\n\n

Konzeptionell ist nichts davon schwierig. Es sind nur viele Dateien. Mehrere Dienste, die in sinnvoller Reihenfolge neu gestartet werden m\u00fcssen. Fast keine Toleranz f\u00fcr einen Tippfehler, besonders wenn man das unter Druck macht, gleich nachdem man etwas gefunden hat, das man nicht finden wollte. Genau diese Kombination ist der Grund, warum sich ISPConfig-Zugangsdaten rotieren von Hand immer riskanter anf\u00fchlte, als die Aufgabe selbst sein sollte. Deshalb habe ich reset_DB_password.sh geschrieben, nachdem ich das Problem mehr als einmal selbst durchgemacht hatte.<\/p>\n\n\n\n

Was reset_DB_password.sh tats\u00e4chlich macht<\/h2>\n\n\n\n

reset_DB_password.sh erkennt, ob der Knoten Standalone, Master oder Slave ist. Dann f\u00fchrt es nur die Phasen aus, die diese Rolle ben\u00f6tigt. Genau so, wie man ISPConfig-Zugangsdaten rotieren sollte: in der richtigen Reihenfolge, f\u00fcr die richtige Rolle.<\/p>\n\n\n\n

Phase A rotiert das lokale MySQL-Root-Passwort. Das ist das Passwort, mit dem ISPConfig selbst die Datenbank jeder gehosteten Website verwaltet. Das Skript aktualisiert mysql_clientdb.conf entsprechend dem neuen Wert.<\/p>\n\n\n\n

Phase B rotiert das Passwort des ispconfig-Kontrollbenutzers. Sie aktualisiert config.inc.php sowohl auf der Server- als auch auf der Interface-Seite. Danach aktualisiert sie die passenden Zugangsdaten in Dovecot, Pure-FTPd und Postfix, damit Mail und FTP weiter authentifizieren, ohne einen separaten manuellen Durchgang durch drei weitere Konfigurationsdateien.<\/p>\n\n\n\n

Phase C l\u00e4uft nur auf einem Slave. Sie verbindet sich remote mit der Datenbank des Masters. Dort rotiert sie das Passwort des Slave-Benutzers und aktualisiert anschlie\u00dfend lokal dbmaster_password, damit die Replikation weiter korrekt gegen den neuen Wert authentifiziert.<\/p>\n\n\n\n

Nach Phase B bietet das Skript an, Dovecot, Pure-FTPd und Postfix f\u00fcr einen neu zu starten. Ich sage fast immer Ja. Wenn man ISPConfig-Zugangsdaten rotiert und dabei einen Mail-Dienst mit dem alten Passwort weiterlaufen l\u00e4sst, ist man nicht fertig, man ist nur still kaputt. Der Neustart im gleichen Durchlauf, direkt nachdem sich die Konfigurationsdateien ge\u00e4ndert haben, h\u00e4lt das Ganze in einem kurzen Wartungsfenster statt in drei separaten, die man sp\u00e4ter entdeckt.<\/p>\n\n\n\n

Backups, bevor sich irgendetwas \u00e4ndert<\/h2>\n\n\n\n

Bevor es auch nur eine Datei anfasst, erstellt das Skript eine vollst\u00e4ndige rsync-Kopie von \/usr\/local\/ispconfig\/ in einem zeitgestempelten Ordner. Es versucht au\u00dferdem einen nicht blockierenden mysqldump der Datenbanken mysql und dbispconfig. Nicht blockierend mit Absicht: Ich schlie\u00dfe lieber eine Rotation der Datenbank-Zugangsdaten ab, als auf einen Dump zu warten, der aus irgendeinem unzusammenh\u00e4ngenden Grund h\u00e4ngen bleibt. Jede Konfigurationsdatei, die bearbeitet wird, bekommt erst ihre eigene .bak-Kopie, bevor auch nur eine Zeichenkette darin ersetzt wird.<\/p>\n\n\n\n

Nichts davon ersetzt eine unabh\u00e4ngige Backup-Strategie. Ich mache weiterhin ein separates Snapshot oder ein vollst\u00e4ndiges Backup, bevor ich das auf einem Server ausf\u00fchre, der wirklich wichtig ist. Der eigene Disclaimer des Skripts sagt dasselbe, nur direkter, als ich es gerade getan habe.<\/p>\n\n\n\n

Erst der Trockenlauf, jedes Mal<\/h2>\n\n\n\n

Jede Phase fragt nach Best\u00e4tigung, bevor irgendetwas ge\u00e4ndert wird. –dry-run simuliert einen kompletten Durchlauf, ohne eine einzige Datei zu ber\u00fchren. Ich benutze dry-run zuerst auf jedem Server, jedes Mal. Auch auf solchen, auf denen ich schon einmal Zugangsdaten rotiert habe und die ich zu kennen glaube. –skip-local-root \u00fcberspringt Phase A, f\u00fcr den Fall, dass nur das Passwort des Kontrollbenutzers rotiert werden muss. –role=master oder –role=slave \u00fcberschreibt die automatische Erkennung, f\u00fcr den seltenen Fall, dass sie die Topologie eines Servers nicht selbst korrekt erkennt.<\/p>\n\n\n\n

Die erzeugten Passw\u00f6rter sind 32 Zeichen lang, nur Buchstaben und Ziffern. Lang genug, um Raten zu widerstehen. Einfach genug, dass die Parser von MySQL und PHP niemals \u00fcber ein vereinzeltes Sonderzeichen in einer Verbindungszeichenfolge stolpern. Ich habe das Skript auf ISPConfig 3.3.1p1 getestet. Gegen \u00e4ltere oder neuere Zweige habe ich es nicht laufen lassen. Ich w\u00fcrde dort kein identisches Verhalten annehmen, ohne es selbst vorher zu pr\u00fcfen.<\/p>\n\n\n\n

Die Rolle eines Knotens ist nicht immer auf den ersten Blick offensichtlich, besonders auf einem Server, den man geerbt und nicht selbst aufgebaut hat. Deshalb gibt es –role, und deshalb lohnt es sich, die Ausgabe des Trockenlaufs beim ersten Mal Zeile f\u00fcr Zeile zu lesen, nicht nur zu \u00fcberfliegen. Ich best\u00e4tige lieber zwei Minuten lang, dass ein Slave wirklich ein Slave ist, als es mitten in der Rotation auf die harte Tour herauszufinden.<\/p>\n\n\n\n

Was ich dir sagen w\u00fcrde, bevor du es ausf\u00fchrst<\/h2>\n\n\n\n

Hinweis<\/strong>: Das Skript wird wie es ist, zu Informationszwecken bereitgestellt. Die Nutzung erfolgt ausschlie\u00dflich auf eigenes Risiko: Ich \u00fcbernehme keine Verantwortung f\u00fcr Datenverlust, Ausfallzeiten oder Fehler, die durch falsche Anwendung, Ver\u00e4nderung des Codes oder einen anderen Kontext als den, in dem ich es selbst einsetze, entstehen. Erstelle immer ein unabh\u00e4ngiges Backup oder einen VM-Snapshot, bevor du es in Produktion ausf\u00fchrst, unabh\u00e4ngig davon, was der eigene Backup-Schritt des Skripts bereits f\u00fcr dich erfasst.<\/p>\n\n\n\n

Es ist freie Software. Du darfst sie weiterverbreiten und ver\u00e4ndern, mit Nennung meines Namens als urspr\u00fcnglichen Autor. Der Quellcode von reset_DB_password.sh, und der Rest der ispconfig-fast-tools-Sammlung, liegt auf GitHub unter github.com\/matteocisilino\/ispconfig-fast-tools<\/a>.<\/p>\n\n\n\n

ISPConfig-Zugangsdaten rotieren ist eine Gewohnheit, kein Aufr\u00e4umjob<\/h2>\n\n\n\n

Datenbank-Zugangsdaten nach einem best\u00e4tigten Einbruch zu rotieren, ist einfach kompetente Reaktion auf einen Sicherheitsvorfall. Die meisten Administratoren w\u00fcrden es tun, ohne dass man es ihnen zweimal sagen muss. Die schwerere Gewohnheit ist, es auch nach einem blo\u00df vermuteten Einbruch zu tun, bevor jemand Beweise hat. Das ist die einzige Version des Plans, die den Schaden tats\u00e4chlich begrenzt, solange er noch begrenzbar ist. Ein Skript, das die richtigen Phasen f\u00fcr die Rolle eines Servers ausf\u00fchrt, zuerst eigene Backups erstellt und mich den ganzen Vorgang per Trockenlauf pr\u00fcfen l\u00e4sst, bevor irgendetwas Reales ber\u00fchrt wird. Das macht die Gewohnheit praktisch an einem Dienstagabend, statt theoretisch in einem Blogartikel.<\/p>\n\n\n\n

ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix und die anderen genannten Namen sind Marken ihrer jeweiligen Inhaber. Sie werden hier nur zur Identifikation der Produkte verwendet.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Wie ich ISPConfig-Zugangsdaten rotieren lasse, sobald ich einen Einbruch vermute: mit reset_DB_password.sh, Backups und Dry-Run, Phase f\u00fcr Phase f\u00fcr Standalone-, Master- und Slave-Knoten.<\/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":[363],"tags":[342,543,383,294,373,542],"class_list":["post-1415","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server-datenbanken","tag-bash-skript","tag-incident-response","tag-ispconfig-de","tag-mysql-de","tag-server-management-de","tag-zugangsdaten-rotation"],"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