So sichern Sie MySQL/MariaDB-Server

Nach Angriffen auf MongoDB-Datenbanken haben wir kürzlich auch gesehen, dass MySQL-Server Ziel von Ransomware sind. Angesichts der zunehmenden Akzeptanz von Public und Private Clouds sollte dies nicht überraschen. Das Ausführen einer schlecht konfigurierten Datenbank in der Cloud kann zu einer großen Belastung werden.

In diesem Blogpost geben wir Ihnen eine Reihe von Tipps, wie Sie Ihre MySQL- oder MariaDB-Server schützen und sichern können.

Verstehen des Angriffsvektors

Zitat von SCMagazine:
“Der Angriff beginnt mit Brute-Force-Erzwingen des Root-Passworts für die MySQL-Datenbank. Nach dem Einloggen werden die MySQL-Datenbanken und -Tabellen abgerufen. Der Angreifer erstellt dann eine neue Tabelle namens „WARNING“, die eine Kontakt-E-Mail-Adresse, eine Bitcoin-Adresse und eine Zahlungsaufforderung enthält. ”

Basierend auf dem Artikel beginnt der Angriffsvektor damit, das MySQL-Root-Passwort per Brute-Force-Methode zu erraten. Ein Brute-Force-Angriff besteht darin, dass ein Angreifer viele Passwörter oder Passphrasen ausprobiert, in der Hoffnung, sie schließlich richtig zu erraten. Das bedeutet, dass kurze Passwörter normalerweise ziemlich schnell entdeckt werden können, aber längere Passwörter können Tage oder Monate dauern.

Brute-Force ist ein gängiger Angriff, der jedem Dienst widerfahren würde. Leider gibt es für MySQL (und viele andere DBMS) keine sofort einsatzbereite Funktion, die Brute-Force-Angriffe von bestimmten Adressen während der Benutzerauthentifizierung erkennt und blockiert. MySQL erfasst jedoch Authentifizierungsfehler im Fehlerprotokoll.

Überprüfen Sie Ihre Passwortrichtlinie

Die Überprüfung der MySQL-Kennwortrichtlinie ist immer der erste Schritt zum Schutz Ihres Servers. Das MySQL-Root-Passwort sollte stark genug sein und eine Kombination aus Buchstaben, Zahlen und Symbolen enthalten (was es schwerer zu merken macht) und an einem sicheren Ort gespeichert werden. Ändern Sie das Passwort regelmäßig, mindestens jedoch jedes Kalenderquartal. Basierend auf dem Angriffsvektor ist dies der schwächste Punkt, auf den Hacker abzielen. Wenn Ihnen Ihre Daten wichtig sind, sollten Sie diesen Teil nicht übersehen.

MySQL-Bereitstellungen, die von ClusterControl durchgeführt werden, folgen immer den bewährten Sicherheitsverfahren des Anbieters, zum Beispiel wird während GRANT kein Wildcard-Host definiert, und vertrauliche Anmeldeinformationen, die in der Konfigurationsdatei gespeichert sind, sind nur für den Root-Benutzer des Betriebssystems zulässig. Wir empfehlen unseren Benutzern dringend, während der Bereitstellungsphase ein sicheres Passwort anzugeben.

In einer Standardproduktionsumgebung befinden sich Datenbankserver normalerweise auf einer niedrigeren Ebene. Diese Ebene sollte geschützt und nur von der oberen Ebene aus zugänglich sein, z. B. Anwendung oder Load Balancer. Wenn sich die Datenbank zusammen mit der Anwendung befindet, können Sie sogar gegen nicht-lokale Adressen sperren und stattdessen die MySQL-Socket-Datei verwenden (weniger Overhead und sicherer).

Hier ist die Konfiguration des Parameters "bind-address" von entscheidender Bedeutung. Beachten Sie, dass die MySQL-Bindung entweder auf keine, eine oder alle IP-Adressen (0.0.0.0) auf dem Server beschränkt ist. Wenn Sie keine Wahl haben und MySQL alle Netzwerkschnittstellen abhören müssen, beschränken Sie den Zugriff auf den MySQL-Dienst von bekannten guten Quellen. Verwenden Sie eine Firewallanwendung oder Sicherheitsgruppe, um den Zugriff nur von Hosts auf die Whitelist zu setzen, die direkt auf die Datenbank zugreifen müssen.

Manchmal muss der MySQL-Server zu Integrationszwecken (z. B. Überwachung, Prüfung, Sicherung usw.) einem öffentlichen Netzwerk ausgesetzt werden. Das ist in Ordnung, solange Sie einen Rahmen darum ziehen. Lassen Sie nicht zu, dass unerwünschte Quellen den MySQL-Server „sehen“. Sie können wetten, wie viele Menschen auf der Welt wissen, dass 3306 der Standardport für den MySQL-Dienst ist, und indem ein Angreifer einfach einen Port-Scan gegen eine Netzwerkadresse durchführt, kann ein Angreifer in weniger als einer Minute eine Liste exponierter MySQL-Server im Subnetz erstellen. Verwenden Sie am besten einen benutzerdefinierten MySQL-Port, indem Sie den "port"-Parameter in der MySQL-Konfigurationsdatei konfigurieren, um das Gefährdungsrisiko zu minimieren.

Lesen Sie die Benutzerrichtlinie durch

Beschränken Sie bestimmte Benutzer auf die kritischen Administrationsrechte, insbesondere GRANT, SUPER und PROCESS. Sie können auch super_read_only aktivieren, wenn der Server ein Slave ist, nur verfügbar auf MySQL 5.7.8 und Percona Server 5.6.21 und höher (leider nicht mit MariaDB). Wenn diese Option aktiviert ist, lässt der Server keine Aktualisierungen zu, abgesehen von der Aktualisierung der Replikations-Repositories, wenn Slave-Statusprotokolle Tabellen sind, selbst für Benutzer mit SUPER-Berechtigung. Entfernen Sie die standardmäßige Testdatenbank und alle Benutzer mit leeren Passwörtern, um den Umfang des Eindringens einzuschränken. Dies ist eine der Sicherheitsprüfungen, die von ClusterControl durchgeführt werden, das als Datenbankberater implementiert ist.

Es ist auch eine gute Idee, die Anzahl der zulässigen Verbindungen auf ein einzelnes Konto zu beschränken. Sie können dies tun, indem Sie die Variable max_user_connections in mysqld setzen (der Standardwert ist 0, gleich unbegrenzt) oder die Ressourcensteuerungsoptionen in GRANT/CREATE USER/ALTER USER-Anweisungen verwenden. Die GRANT-Anweisung unterstützt die Beschränkung der Anzahl gleichzeitiger Verbindungen zum Server durch ein Konto, zum Beispiel:

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

Der standardmäßige Administrator-Benutzername auf dem MySQL-Server ist „root“. Hacker versuchen oft, Zugriff auf seine Berechtigungen zu erhalten. Um diese Aufgabe viel schwieriger zu machen, benennen Sie „root“ in etwas anderes um. MySQL-Benutzernamen können bis zu 32 Zeichen lang sein (16 Zeichen vor MySQL 5.7.8). Es ist möglich, einen längeren Benutzernamen für den Super-Admin-Benutzer zu verwenden, indem Sie die RENAME-Anweisung wie unten gezeigt verwenden:

mysql> RENAME USER root TO new_super_administrator_username;

Eine Randnotiz für ClusterControl-Benutzer:ClusterControl muss den MySQL-Root-Benutzer und das Passwort kennen, um den Datenbankserver für Sie zu automatisieren und zu verwalten. Standardmäßig wird nach „root“ gesucht. Wenn Sie den Root-Benutzer in etwas anderes umbenennen, geben Sie „monitored_mysql_root_user={new_user}“ in cmon_X.cnf an (wobei X die Cluster-ID ist) und starten Sie den CMON-Dienst neu, um die Änderung zu übernehmen.

Sicherungsrichtlinie

Auch wenn die Hacker erklärten, dass Sie Ihre Daten zurückerhalten würden, sobald das Lösegeld bezahlt wurde, war dies normalerweise nicht der Fall. Eine Erhöhung der Sicherungshäufigkeit würde die Möglichkeit erhöhen, Ihre gelöschten Daten wiederherzustellen. Anstelle einer vollständigen Sicherung einmal pro Woche mit täglicher inkrementeller Sicherung können Sie beispielsweise eine vollständige Sicherung einmal pro Tag mit stündlicher inkrementeller Sicherung planen. Mit der Sicherungsverwaltungsfunktion von ClusterControl können Sie dies ganz einfach tun und Ihre Daten wiederherstellen, wenn etwas schief geht.

Wenn Sie Binärprotokolle (Binlogs) aktiviert haben, ist das sogar noch besser. Sie können jeden Tag ein vollständiges Backup erstellen und die Binärprotokolle sichern. Binlogs sind wichtig für die Point-in-Time-Wiederherstellung und sollten regelmäßig als Teil Ihres Backup-Verfahrens gesichert werden. DBAs vermissen diese einfache Methode, die jeden Cent wert ist. Falls Sie gehackt wurden, können Sie immer bis zum letzten Punkt vor dem Ereignis wiederherstellen, vorausgesetzt, die Hacker haben die Binärprotokolle nicht gelöscht. Beachten Sie, dass das Löschen von Binärprotokollen nur möglich ist, wenn der Angreifer SUPER-Privilegien hat.

Eine weitere wichtige Sache ist, dass die Sicherungsdateien wiederherstellbar sein müssen. Überprüfen Sie die Sicherungen von Zeit zu Zeit und vermeiden Sie böse Überraschungen, wenn Sie eine Wiederherstellung durchführen müssen.

Schützen Sie Ihren Web-/Anwendungsserver

Nun, wenn Sie Ihre MySQL-Server isoliert haben, besteht für die Angreifer immer noch die Möglichkeit, über Web- oder Anwendungsserver darauf zuzugreifen. Durch Einschleusen eines schädlichen Skripts (z. B. Cross-Site Scripting, SQL-Injection) auf der Zielwebsite kann man in das Anwendungsverzeichnis gelangen und die Anwendungsdateien lesen. Diese können vertrauliche Informationen enthalten, beispielsweise die Anmeldeinformationen für die Datenbank. Wenn man sich das ansieht, kann sich ein Angreifer einfach in die Datenbank einloggen, alle Tabellen löschen und eine „Lösegeld“-Tabelle darin hinterlassen. Es muss nicht unbedingt ein MySQL-Root-Benutzer sein, um ein Opfer freizukaufen.

Es gibt Tausende von Möglichkeiten, einen Webserver zu kompromittieren, und Sie können den eingehenden Port 80 oder 443 für diesen Zweck nicht wirklich schließen. Eine weitere Schutzebene ist erforderlich, um Ihren Webserver vor HTTP-basierten Injektionen zu schützen. Sie können Web Application Firewall (WAF) wie Apache ModSecurity, NAXSI (WAF für nginx), WebKnight (WAF für IIS) verwenden oder Ihre Webserver einfach in einem sicheren Content Delivery Network (CDN) wie CloudFlare, Akamai oder Amazon CloudFront betreiben /P>

Immer auf dem Laufenden bleiben

Sie haben wahrscheinlich schon von dem kritischen Zero-Day-MySQL-Exploit gehört, bei dem ein nicht privilegierter Benutzer sich selbst zum Superuser eskalieren kann? Es klingt beängstigend. Glücklicherweise haben alle bekannten Anbieter ihr Repository aktualisiert, um eine Fehlerbehebung für dieses Problem aufzunehmen.

Für den Produktionseinsatz wird dringend empfohlen, die MySQL/MariaDB-Pakete aus dem Repository des Anbieters zu installieren. Verlassen Sie sich nicht auf das standardmäßige Betriebssystem-Repository, wo die Pakete normalerweise veraltet sind. Wenn Sie in einer Clusterumgebung wie Galera Cluster oder sogar MySQL Replication arbeiten, haben Sie immer die Wahl, das System mit minimaler Ausfallzeit zu patchen. Machen Sie dies zur Routine und versuchen Sie, den Upgrade-Vorgang so weit wie möglich zu automatisieren.

ClusterControl unterstützt Rolling-Upgrades für Nebenversionen (jeweils ein Knoten) für MySQL/MariaDB mit einem einzigen Klick. Das Upgrade von Hauptversionen (z. B. von MySQL 5.6 auf MySQL 5.7) erfordert in der Regel die Deinstallation der vorhandenen Pakete, und die Automatisierung ist eine riskante Aufgabe. Sorgfältige Planung und Tests sind für solche Upgrades erforderlich.

Schlussfolgerung

Ransomware ist ein leicht zu verdienender Goldschatz. Wir werden in Zukunft wahrscheinlich mehr Sicherheitsverletzungen sehen, und es ist besser, Maßnahmen zu ergreifen, bevor etwas passiert. Hacker zielen auf viele anfällige Server da draußen ab, und sehr wahrscheinlich wird sich dieser Angriff auch auf andere Datenbanktechnologien ausweiten. Der Schutz Ihrer Daten ist eine ständige Herausforderung für Datenbankadministratoren. Der wahre Feind ist nicht der Täter, sondern unsere Einstellung zum Schutz unserer kritischen Vermögenswerte.