ISPConfig-Zugangsdaten rotieren bedeutet für mich: handeln, sobald ich einen Einbruch vermute. Nicht erst, nachdem ich einen bestätigt 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ären kann, in einem öffentlichen Backup. Ab diesem Punkt muss jedes Passwort, das zu diesem Datenbank-Stack gehört, neu sein. Überprüft. Dokumentiert. Nicht einfach als unbedenklich angenommen.
Wann hört Rotation auf, optional zu sein?
Ein paar Szenarien bringen das Thema regelmäßig genug zur Sprache, dass ich einen Rotationsplan dafür bereithalte. Ich improvisiere lieber keinen unter Druck.
Ein Plugin oder CMS auf einer gehosteten Website wird kompromittiert. Über einen echten Fall auf dieser Art von Server habe ich hier geschrieben: PHP2Shell: So habe ich meine Server bis zum Patch geschützt, eine PHP-Schwachstelle, die einem Angreifer erlaubte, eine Webshell abzulegen, bevor es einen Patch gab. Sobald eine Webshell unter einem Hosting-Benutzer läuft, 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ür die eigene Datenbank des Kontrollpanels. Nicht nur das eine Zugangsdatum, hinter dem der Angreifer eigentlich her war.
Eine Konfigurationsdatei landet irgendwo, wo sie nicht hingehört. Ein Backup-Archiv, das in einem öffentlichen 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.
Ein Systemadministrator verlässt das Team. Wie einvernehmlich der Abschied auch war, gemeinsam genutzte Datenbank-Zugangsdaten, die diese Person einmal hatte, sind Zugangsdaten, denen ich nicht mehr vollständig vertraue. Vertrauen wird nicht automatisch übertragen, wenn jemand zur Tür hinausgeht.
Ein vermuteter Einbruch, selbst ein unbestätigter. Dieser Fall lässt sich am schwersten jemandem erklären, 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ötige Rotation kostet einen Nachmittag. Eine ausgelassene, nach einem echten Einbruch, kann jede Website kosten, die der Server hostet.
Warum ISPConfig-Zugangsdaten rotieren von Hand so fehleranfällig ist
Als ich die Datenbank-Zugangsdaten von ISPConfig zum ersten Mal von Hand rotiert habe, habe ich unterschätzt, wie viele Dateien betroffen sind. Sie müssen alle zusammen geändert werden, sonst geht ein paar Stunden später irgendwo leise etwas kaputt.
Es gibt config.inc.php auf der Server-Seite und eine zweite Kopie auf der Interface-Seite. Beide müssen 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ührung. Dovecot, Pure-FTPd und Postfix führen jeweils eine eigene Kopie einiger dieser Zugangsdaten. Mail und FTP können still aufhören, sich zu authentifizieren, wenn man den Datenbank-Benutzer aktualisiert und dabei nur eine dieser drei Dienste vergisst.
Dann gibt es die Master/Slave-Topologie, die einige meiner Setups verwenden. Ein Slave-Knoten authentifiziert sich über 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.
Konzeptionell ist nichts davon schwierig. Es sind nur viele Dateien. Mehrere Dienste, die in sinnvoller Reihenfolge neu gestartet werden müssen. Fast keine Toleranz für 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ühlte, als die Aufgabe selbst sein sollte. Deshalb habe ich reset_DB_password.sh geschrieben, nachdem ich das Problem mehr als einmal selbst durchgemacht hatte.
Was reset_DB_password.sh tatsächlich macht
reset_DB_password.sh erkennt, ob der Knoten Standalone, Master oder Slave ist. Dann führt es nur die Phasen aus, die diese Rolle benötigt. Genau so, wie man ISPConfig-Zugangsdaten rotieren sollte: in der richtigen Reihenfolge, für die richtige Rolle.
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.
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.
Phase C läuft nur auf einem Slave. Sie verbindet sich remote mit der Datenbank des Masters. Dort rotiert sie das Passwort des Slave-Benutzers und aktualisiert anschließend lokal dbmaster_password, damit die Replikation weiter korrekt gegen den neuen Wert authentifiziert.
Nach Phase B bietet das Skript an, Dovecot, Pure-FTPd und Postfix für 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ässt, ist man nicht fertig, man ist nur still kaputt. Der Neustart im gleichen Durchlauf, direkt nachdem sich die Konfigurationsdateien geändert haben, hält das Ganze in einem kurzen Wartungsfenster statt in drei separaten, die man später entdeckt.
Backups, bevor sich irgendetwas ändert
Bevor es auch nur eine Datei anfasst, erstellt das Skript eine vollständige rsync-Kopie von /usr/local/ispconfig/ in einem zeitgestempelten Ordner. Es versucht außerdem einen nicht blockierenden mysqldump der Datenbanken mysql und dbispconfig. Nicht blockierend mit Absicht: Ich schließe lieber eine Rotation der Datenbank-Zugangsdaten ab, als auf einen Dump zu warten, der aus irgendeinem unzusammenhängenden Grund hängen bleibt. Jede Konfigurationsdatei, die bearbeitet wird, bekommt erst ihre eigene .bak-Kopie, bevor auch nur eine Zeichenkette darin ersetzt wird.
Nichts davon ersetzt eine unabhängige Backup-Strategie. Ich mache weiterhin ein separates Snapshot oder ein vollständiges Backup, bevor ich das auf einem Server ausführe, der wirklich wichtig ist. Der eigene Disclaimer des Skripts sagt dasselbe, nur direkter, als ich es gerade getan habe.
Erst der Trockenlauf, jedes Mal
Jede Phase fragt nach Bestätigung, bevor irgendetwas geändert wird. –dry-run simuliert einen kompletten Durchlauf, ohne eine einzige Datei zu berühren. 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 überspringt Phase A, für den Fall, dass nur das Passwort des Kontrollbenutzers rotiert werden muss. –role=master oder –role=slave überschreibt die automatische Erkennung, für den seltenen Fall, dass sie die Topologie eines Servers nicht selbst korrekt erkennt.
Die erzeugten Passwörter sind 32 Zeichen lang, nur Buchstaben und Ziffern. Lang genug, um Raten zu widerstehen. Einfach genug, dass die Parser von MySQL und PHP niemals über ein vereinzeltes Sonderzeichen in einer Verbindungszeichenfolge stolpern. Ich habe das Skript auf ISPConfig 3.3.1p1 getestet. Gegen ältere oder neuere Zweige habe ich es nicht laufen lassen. Ich würde dort kein identisches Verhalten annehmen, ohne es selbst vorher zu prüfen.
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ür Zeile zu lesen, nicht nur zu überfliegen. Ich bestätige lieber zwei Minuten lang, dass ein Slave wirklich ein Slave ist, als es mitten in der Rotation auf die harte Tour herauszufinden.
Was ich dir sagen würde, bevor du es ausführst
Hinweis: Das Skript wird wie es ist, zu Informationszwecken bereitgestellt. Die Nutzung erfolgt ausschließlich auf eigenes Risiko: Ich übernehme keine Verantwortung für Datenverlust, Ausfallzeiten oder Fehler, die durch falsche Anwendung, Veränderung des Codes oder einen anderen Kontext als den, in dem ich es selbst einsetze, entstehen. Erstelle immer ein unabhängiges Backup oder einen VM-Snapshot, bevor du es in Produktion ausführst, unabhängig davon, was der eigene Backup-Schritt des Skripts bereits für dich erfasst.
Es ist freie Software. Du darfst sie weiterverbreiten und verändern, mit Nennung meines Namens als ursprünglichen 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.
ISPConfig-Zugangsdaten rotieren ist eine Gewohnheit, kein Aufräumjob
Datenbank-Zugangsdaten nach einem bestätigten Einbruch zu rotieren, ist einfach kompetente Reaktion auf einen Sicherheitsvorfall. Die meisten Administratoren würden es tun, ohne dass man es ihnen zweimal sagen muss. Die schwerere Gewohnheit ist, es auch nach einem bloß vermuteten Einbruch zu tun, bevor jemand Beweise hat. Das ist die einzige Version des Plans, die den Schaden tatsächlich begrenzt, solange er noch begrenzbar ist. Ein Skript, das die richtigen Phasen für die Rolle eines Servers ausführt, zuerst eigene Backups erstellt und mich den ganzen Vorgang per Trockenlauf prüfen lässt, bevor irgendetwas Reales berührt wird. Das macht die Gewohnheit praktisch an einem Dienstagabend, statt theoretisch in einem Blogartikel.
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.
Schreibe einen Kommentar