MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

So schützen Sie Ihre MySQL- und MariaDB-Datenbank vor Cyberangriffen, wenn Sie sich in einem öffentlichen Netzwerk befinden

Manchmal ist es unvermeidlich, MySQL-Datenbankserver in einem öffentlichen oder exponierten Netzwerk auszuführen. Dies ist eine übliche Einrichtung in einer gemeinsam genutzten Hosting-Umgebung, in der ein Server mit mehreren Diensten konfiguriert ist und häufig auf demselben Server wie der Datenbankserver ausgeführt wird. Für diejenigen, die diese Art von Setup haben, sollten Sie immer eine Art Schutz gegen Cyberangriffe wie Denial-of-Service, Hacking, Cracking, Datenschutzverletzungen haben; all das kann zu Datenverlust führen. Dies sind Dinge, die wir für unseren Datenbankserver immer vermeiden möchten.

Hier sind einige der Tipps, die wir tun können, um unsere MySQL- oder MariaDB-Sicherheit zu verbessern.

Scannen Sie Ihre Datenbankserver regelmäßig

Der Schutz vor schädlichen Dateien auf dem Server ist sehr wichtig. Scannen Sie den Server regelmäßig auf Viren, Spyware, Malware oder Rootkits, insbesondere wenn der Datenbankserver zusammen mit anderen Diensten wie Mailserver, HTTP, FTP, DNS, WebDAV, Telnet usw. installiert ist. In der Regel stammten die meisten Probleme mit Datenbank-Hacks von der Anwendungsebene, die dem öffentlichen Netzwerk gegenübersteht. Daher ist es wichtig, alle Dateien zu scannen, insbesondere Web-/Anwendungsdateien, da sie einer der Einstiegspunkte zum Zugriff auf den Server sind. Wenn diese kompromittiert sind, kann der Hacker in das Anwendungsverzeichnis gelangen und die Anwendungsdateien lesen. Diese können vertrauliche Informationen enthalten, beispielsweise die Anmeldeinformationen für die Datenbank.

ClamAV ist eine der bekanntesten und vertrauenswürdigsten Antivirenlösungen für eine Vielzahl von Betriebssystemen, einschließlich Linux. Es ist kostenlos und sehr einfach zu installieren und verfügt über einen ziemlich guten Erkennungsmechanismus, um nach unerwünschten Dingen auf Ihrem Server zu suchen. Planen Sie regelmäßige Scans im Cron-Job, zum Beispiel:

0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.log

Das obige aktualisiert die ClamAV-Virendatenbank, scannt alle Verzeichnisse und Dateien und sendet Ihnen täglich um 3 Uhr morgens eine E-Mail über den Status der Ausführung und einen Bericht.

Verwenden Sie strengere Benutzerrollen und -privilegien

Erlauben Sie beim Erstellen eines MySQL-Benutzers nicht allen Hosts den Zugriff auf den MySQL-Server mit dem Wildcard-Host (%). Sie sollten Ihren MySQL-Host scannen und nach Wildcard-Host-Werten suchen, wie in der folgenden Anweisung gezeigt:

mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user    | host |
+---------+------+
| myadmin | %    |
| sbtest  | %    |
| user1   | %    |
+---------+------+

Strikte oder entferne aus der obigen Ausgabe alle Benutzer, die nur den Wert '%' in der Host-Spalte haben. Benutzer, die remote auf den MySQL-Server zugreifen müssen, können gezwungen werden, die SSH-Tunneling-Methode zu verwenden, die keine Remote-Host-Konfiguration für MySQL-Benutzer erfordert. Die meisten MySQL-Verwaltungsclients wie MySQL Workbench und HeidiSQL können so konfiguriert werden, dass sie sich über SSH-Tunneling mit einem MySQL-Server verbinden, daher ist es möglich, die Fernverbindung für MySQL-Benutzer vollständig zu eliminieren.

Beschränken Sie außerdem das SUPER-Privileg auf nur Benutzer von localhost oder verbinden Sie sich über eine UNIX-Socket-Datei. Seien Sie vorsichtiger, wenn Sie Nicht-Root-Benutzern das FILE-Privileg zuweisen, da es das Lesen und Schreiben von Dateien auf dem Server mit den Anweisungen LOAD DATA INFILE und SELECT ... INTO OUTFILE erlaubt. Jeder Benutzer, dem dieses Privileg gewährt wird, kann auch jede Datei lesen oder schreiben, die der MySQL-Server lesen oder schreiben kann.

Ändern Sie die Standardeinstellungen der Datenbank

Indem wir uns von der standardmäßigen Einrichtung, Benennung und Konfiguration entfernen, können wir den Angriffsvektor auf eine Reihe von Faktoren reduzieren. Die folgenden Aktionen sind einige Beispiele für Standardkonfigurationen, die DBAs leicht ändern könnten, aber im Zusammenhang mit MySQL häufig übersehen werden:

  • Ändern Sie den standardmäßigen MySQL-Port auf einen anderen als 3306.
  • Benennen Sie den MySQL-Root-Benutzernamen in einen anderen Namen als "root" um.
  • Erzwingen Sie den Kennwortablauf und reduzieren Sie die Kennwortlebensdauer für alle Benutzer.
  • Wenn sich MySQL zusammen mit den Anwendungsservern befindet, erzwingen Sie die Verbindung nur über die UNIX-Socket-Datei und hören Sie auf, Port 3306 auf alle IP-Adressen abzuhören.
  • Erzwingen Sie die Client-Server-Verschlüsselung und die Server-Server-Replikationsverschlüsselung.

Wir haben dies tatsächlich ausführlich in diesem Blog-Beitrag behandelt, How to Secure MySQL/MariaDB Servers.

Einen verzögerten Slave einrichten

Ein verzögerter Slave ist nur ein typischer Slave, jedoch führt der Slave-Server Transaktionen absichtlich um mindestens eine bestimmte Zeit später als der Master aus, verfügbar ab MySQL 5.6. Grundsätzlich wird ein vom Master empfangenes Ereignis nicht ausgeführt, bis mindestens N Sekunden später als seine Ausführung auf dem Master. Das Ergebnis ist, dass der Slave den Zustand des Masters vor einiger Zeit in der Vergangenheit widerspiegelt.

Ein verzögerter Slave kann verwendet werden, um Daten innerhalb der Verzögerungszeit wiederherzustellen, was hilfreich wäre, wenn das Problem sofort gefunden wird. Angenommen, wir haben einen Slave mit einer 6-stündigen Verzögerung vom Master konfiguriert. Wenn unsere Datenbank innerhalb dieses Zeitraums geändert oder gelöscht wurde (versehentlich von einem Entwickler oder absichtlich von einem Hacker), besteht für uns die Möglichkeit, zu dem Moment direkt vor dem Ereignis zurückzukehren, indem wir den aktuellen Master stoppen und dann den Slave-Server hochfahren bis zu einem bestimmten Punkt mit dem folgenden Befehl:

# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;

Dabei ist „xxxxx“ die binäre Protokolldatei und „yyyyy“ die Position kurz vor dem Eintreten des Notfalls (verwenden Sie das mysqlbinlog-Tool, um diese Ereignisse zu untersuchen). Befördern Sie schließlich den Slave zum neuen Master und Ihr MySQL-Dienst ist jetzt wieder wie gewohnt betriebsbereit. Diese Methode ist wahrscheinlich der schnellste Weg, um Ihre MySQL-Datenbank in der Produktionsumgebung wiederherzustellen, ohne ein Backup neu laden zu müssen. Eine Reihe verzögerter Slaves mit unterschiedlicher Dauer zu haben, wie in diesem Blog, Multiple Delayed Replication Slaves for Disaster Recovery with Low RTO, gezeigt, wie man kostengünstige verzögerte Replikationsserver auf Docker-Containern einrichtet.

Binäre Protokollierung aktivieren

Es wird allgemein empfohlen, die binäre Protokollierung zu aktivieren, auch wenn Sie auf einem eigenständigen MySQL/MariaDB-Server laufen. Das Binärlog enthält Informationen zu SQL-Anweisungen, die Datenbankinhalte ändern. Die Informationen werden in Form von "Ereignissen" gespeichert, die die Änderungen beschreiben. Trotz der Auswirkungen auf die Leistung haben Sie mit dem Binärprotokoll die Möglichkeit, Ihren Datenbankserver bis zu dem genauen Punkt wiederzugeben, an dem er wiederhergestellt werden soll, auch bekannt als Point-in-Time-Recovery (PITR). Die binäre Protokollierung ist auch für die Replikation obligatorisch.

Bei aktivierter binärer Protokollierung müssen Sie die binäre Protokolldatei und Positionsinformationen einbeziehen, wenn Sie eine vollständige Sicherung durchführen. Für mysqldump druckt die Verwendung des Flags --master-data mit dem Wert 1 oder 2 die erforderlichen Informationen aus, die wir als Ausgangspunkt für die Aktualisierung der Datenbank verwenden können, wenn wir später die Binärprotokolle wiedergeben.

Wenn die binäre Protokollierung aktiviert ist, können Sie eine weitere coole Wiederherstellungsfunktion namens Flashback verwenden, die im nächsten Abschnitt beschrieben wird.

Flashback aktivieren

Die Flashback-Funktion ist in MariaDB verfügbar, wo Sie die Daten auf den vorherigen Snapshot in einer MySQL-Datenbank oder in einer Tabelle wiederherstellen können. Flashback verwendet mysqlbinlog, um die Rollback-Anweisungen zu erstellen, und benötigt dafür ein VOLLSTÄNDIGES Binärprotokoll-Zeilenbild. Um diese Funktion zu verwenden, muss der MySQL/MariaDB-Server daher wie folgt konfiguriert werden:

[mysqld]
...
binlog_format = ROW
binlog_row_image = FULL

Das folgende Architekturdiagramm veranschaulicht, wie Flashback auf einem der Slaves konfiguriert wird:

Um die Flashback-Operation durchzuführen, müssen Sie zunächst Datum und Uhrzeit ermitteln wenn Sie die Daten "sehen" möchten, oder binäre Protokolldatei und Position. Verwenden Sie dann das Flag --flashback mit dem Dienstprogramm mysqlbinlog, um SQL-Anweisungen zu generieren, um die Daten bis zu diesem Punkt zurückzusetzen. In der generierten SQL-Datei werden Sie feststellen, dass die DELETE-Ereignisse in INSERTs konvertiert werden und umgekehrt, und dass auch WHERE- und SET-Teile der UPDATE-Ereignisse vertauscht werden.

Die folgende Befehlszeile sollte auf dem Slave2 (konfiguriert mit binlog_row_image=FULL) ausgeführt werden:

$ mysqlbinlog --flashback --start-datetime="2020-02-17 01:30:00"  /var/lib/mysql/mysql-bin.000028 -v --database=shop --table=products > flashback_to_2020-02-17_013000.sql

Trennen Sie dann slave2 von der Replikationskette, da wir sie unterbrechen und den Server zum Rollback unserer Daten verwenden werden:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;

Importieren Sie abschließend die generierte SQL-Datei in den MariaDB-Server für den Datenbankshop auf slave2:

$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sql

Wenn das oben Gesagte angewendet wird, befindet sich die Tabelle „Produkte“ auf dem Stand vom 17.02.2020 01:30:00. Technisch gesehen kann die generierte SQL-Datei sowohl auf MariaDB- als auch auf MySQL-Server angewendet werden. Sie könnten auch die mysqlbinlog-Binärdatei vom MariaDB-Server übertragen, damit Sie die Flashback-Funktion auf einem MySQL-Server verwenden können. Die Implementierung von MySQL GTID unterscheidet sich jedoch von MariaDB, daher müssen Sie zum Wiederherstellen der SQL-Datei MySQL GTID deaktivieren.

Ein paar Vorteile der Verwendung von Flashback sind, dass Sie den MySQL/MariaDB-Server nicht stoppen müssen, um diesen Vorgang auszuführen. Wenn die wiederherzustellende Datenmenge gering ist, ist der Flashback-Prozess viel schneller als die Wiederherstellung der Daten aus einer vollständigen Sicherung.

Alle Datenbankabfragen protokollieren

Das allgemeine Protokoll erfasst grundsätzlich jede SQL-Anweisung, die vom Client im MySQL-Server ausgeführt wird. Dies ist jedoch aufgrund der Leistungseinbußen und des Speicherplatzverbrauchs möglicherweise keine beliebte Entscheidung auf einem ausgelasteten Produktionsserver. Wenn es auf die Leistung ankommt, hat die Aktivierung des Binärprotokolls die höhere Priorität. Das allgemeine Protokoll kann während der Laufzeit durch Ausführen der folgenden Befehle aktiviert werden:

mysql> SET global general_log_file='/tmp/mysql.log'; 
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;

Sie können die allgemeine Protokollausgabe auch auf eine Tabelle setzen:

mysql> SET global log_output = 'table';

Sie können dann die standardmäßige SELECT-Anweisung für die mysql.general_log-Tabelle verwenden, um Abfragen abzurufen. Erwarten Sie etwas mehr Leistungseinbußen, wenn Sie mit dieser Konfiguration arbeiten, wie in diesem Blogbeitrag gezeigt.

Andernfalls können Sie externe Überwachungstools verwenden, die Abfrage-Sampling und -Überwachung durchführen können, damit Sie die auf dem Server eingehenden Abfragen filtern und prüfen können. ClusterControl kann verwendet werden, um alle Ihre Abfragen zu sammeln und zusammenzufassen, wie in den folgenden Screenshots gezeigt, in denen wir alle Abfragen filtern, die die DELETE-Zeichenfolge enthalten:

Ähnliche Informationen sind auch auf der obersten Abfrageseite von ProxySQL verfügbar (falls Ihre Anwendung Verbindung über ProxySQL):

Dies kann verwendet werden, um die letzten Änderungen zu verfolgen, die am Datenbankserver vorgenommen wurden und kann auch für Revisionszwecke verwendet werden.

Fazit

Ihre MySQL- und MariaDB-Server müssen jederzeit gut geschützt sein, da sie normalerweise sensible Daten enthalten, um die sich Angreifer kümmern. Sie können ClusterControl auch verwenden, um die Sicherheitsaspekte Ihrer Datenbankserver zu verwalten, wie in diesem Blogbeitrag How to Secure Your Open Source Databases with ClusterControl gezeigt wird.